最新文章专题视频专题问答1问答10问答100问答1000问答2000关键字专题1关键字专题50关键字专题500关键字专题1500TAG最新视频文章推荐1 推荐3 推荐5 推荐7 推荐9 推荐11 推荐13 推荐15 推荐17 推荐19 推荐21 推荐23 推荐25 推荐27 推荐29 推荐31 推荐33 推荐35 推荐37视频文章20视频文章30视频文章40视频文章50视频文章60 视频文章70视频文章80视频文章90视频文章100视频文章120视频文章140 视频2关键字专题关键字专题tag2tag3文章专题文章专题2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章专题3
当前位置: 首页 - 科技 - 知识百科 - 正文

MySQL5.6.7-RC的tpcc-mysql基准测试结果_MySQL

来源:动视网 责编:小采 时间:2020-11-09 18:04:38
文档

MySQL5.6.7-RC的tpcc-mysql基准测试结果_MySQL

MySQL5.6.7-RC的tpcc-mysql基准测试结果_MySQL:bitsCN.com MySQL 5.6.7 RC 前些天发布了,因此我决定使用 tpcc-mysql 对其表现进行测试,包括性能和稳定性方面。 我不能说我的测试过程是完美无瑕的,因为发现了两个 bug : MySQL 5.6.7 在 CREATE INDEX 时锁住了 MySQL 5
推荐度:
导读MySQL5.6.7-RC的tpcc-mysql基准测试结果_MySQL:bitsCN.com MySQL 5.6.7 RC 前些天发布了,因此我决定使用 tpcc-mysql 对其表现进行测试,包括性能和稳定性方面。 我不能说我的测试过程是完美无瑕的,因为发现了两个 bug : MySQL 5.6.7 在 CREATE INDEX 时锁住了 MySQL 5
 bitsCN.com

MySQL 5.6.7 RC 前些天发布了,因此我决定使用 tpcc-mysql 对其表现进行测试,包括性能和稳定性方面。

我不能说我的测试过程是完美无瑕的,因为发现了两个 bug :

  • MySQL 5.6.7 在 CREATE INDEX 时锁住了
  • MySQL 5.6.7-rc 在使用 tpcc-mysql 工作负载测试时崩溃
  • 不晓得是不是因为是 RC 版本的原因,后来向 Oracle 提交一些反馈,下面是详细的测试环境:

  • 测试日期: Oct-2012
  • 测试目的: 测试 MySQL 5.6.7 的表现
  • 硬件换
  • 服务器: Dell PowerEdge R710
  • CPU: 2x Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz
  • 内存: 192GB(这个内存太猛了)
  • 存储: Very Fast PCIe Flash Card
  • 文件系统: ext4
  • 软件
  • 操作系统: CentOS 6.3
  • MySQL 版本: 5.6.7-RC
  • 测试规范
  • 测试工具: tpcc-mysql
  • 测试数据: 2500W (~250GB of data)
  • 测试时间: 总共测试 4000 秒,但只取最后的 2000 秒,避免因为冷启动的问题导致测试结果不准确
  • 不同的测试参数: 使用几组不同的 innodb_buffer_pool_size:13, 25, 50, 75, 100, 125GB ,innodb_buffer_pool_instances: 1 and 8, and innodb_log_file_size: 2x4GB and 2x8GB.
  • 测试结果:

    第一个结果使用的事 2x4GB 的 InnoDB 日志文件:

    我们可看出当 innodb_buffer_pool_instances=8 在很小的 buffer_pool 大小时有很大的不同,而使用大的 buffer_pool 时,innodb_buffer_pool_instances=1 的表现最棒。

    测试结果在大的 buffer_pool 时是很稳定的,原因是 InnoDB 使用异步 flush 模式,在新的 InnoDB flush 机制下以前的问题已经修复。不过 Dimitry 告诉我需要一个更大的 InnoDB 日志文件来获得更稳定的结果。

    下面是 2x4GB vs 2x8GB innodb 日志文件大小的比较:

    很显然,使用更大的日志文件,测试结果更稳定!

    结论:

    innodb_buffer_pool_instances 参数显著的影响测试结果,特别是非常高的 I/O 负载时。

    在 MySQL 5.6 ,最终是可以获得非常稳定的吞吐,但自适应的 flush 机制仍需较大的日志文件。

    MySQL 配置如下:
    01 [mysqld] 02 gdb 03 04 innodb_file_per_table = true 05 innodb_data_file_path = ibdata1:100M:autoextend 06 innodb_flush_method = O_DIRECT 07 innodb_log_buffer_size = 256M 08 09 innodb_flush_log_at_trx_commit = 1 10 innodb_buffer_pool_size = 125G 11 innodb_buffer_pool_instances=8 12 13 innodb_log_file_size = 4G 14 innodb_log_files_in_group = 2 15 #####plugin options 16 innodb_read_io_threads = 16 17 innodb_write_io_threads = 16 18 innodb_io_capacity = 20000 19 innodb_io_capacity_max = 40000 20 21 22 #not innodb options (fixed) 23 port = 3306 24 back_log = 50 25 max_connections = 2000 26 max_prepared_stmt_count=500000 27 max_connect_errors = 10 28 table_open_cache = 2048 29 max_allowed_packet = 16M 30 binlog_cache_size = 16M 31 max_heap_table_size = 64M 32 sort_buffer_size = 4M 33 join_buffer_size = 4M 34 thread_cache_size = 1000 35 query_cache_size = 0 36 query_cache_type = 0 37 ft_min_word_len = 4 38 thread_stack = 192K 39 tmp_table_size = 64M 40 41 server-id = 10 42 #*** MyISAM Specific options 43 key_buffer_size = 8M 44 read_buffer_size = 1M 45 read_rnd_buffer_size = 4M 46 bulk_insert_buffer_size = 8M 47 myisam_sort_buffer_size = 8M 48 myisam_max_sort_file_size = 10G 49 myisam_repair_threads = 1 50 myisam_recover 51 user=root 52 skip-grant-tables

    英文原文,OSCHINA原创翻译

    bitsCN.com

    文档

    MySQL5.6.7-RC的tpcc-mysql基准测试结果_MySQL

    MySQL5.6.7-RC的tpcc-mysql基准测试结果_MySQL:bitsCN.com MySQL 5.6.7 RC 前些天发布了,因此我决定使用 tpcc-mysql 对其表现进行测试,包括性能和稳定性方面。 我不能说我的测试过程是完美无瑕的,因为发现了两个 bug : MySQL 5.6.7 在 CREATE INDEX 时锁住了 MySQL 5
    推荐度:
    标签: 测试 稳定性 mysql
    • 热门焦点

    最新推荐

    猜你喜欢

    热门推荐

    专题
    Top