MySQL 性能比较测试:MySQL 5.6 GA -vs- MySQL 5.5
2014-08-03 20:03
676 查看
时间:2013年11月07日 ⁄ 分类: 数据库技术文档 ⁄ 我要吐槽发评论
MySQL 5.6 GA 发布了,毫无疑问,这是 MySQL 最棒的一个版本。
如果你还不清楚 MySQL 5.6 版本一长串的新特性和改进内容,可以从这里获得了解。
而我这篇文章的主要目的则是性能的测试。
我使用 Sysbench workloads (Read-Only/Read-Write) 来测试。下面是我的测试环境:
硬件配置:
服务器 : 32核 bi-thread (HT) Intel 2300Mhz, 128GB RAM
操作系统 : Oracle Linux 6.2
文件系统 : XFS mounted with "noatime,nodiratime,nobarrier,logbufs=8"
MySQL : 5.6-GA, latest 5.5
MySQL 调整:
配置最主要的不同是 AHI (innodb_adaptive_hash_index) 和 Spin Delay (innodb_spin_wait_delay) -- 而其他的部分在这个测试过程中基本上已经足够好了。
关于 AHI 的影响我之前已经写了很多文章。AHI 主要的困境在于“用还是不用”,在很多情况下它可以帮助因为锁导致的堵塞并加快索引的访问,但在高并发的情况下可能会因为其 btr_search_latch 导致 rw锁争用导致的瓶颈
在 MySQL 5.6 中的 Spin Delay 设置需要特别的注意,因为它在管理内部互斥量和 rw 锁争用时扮演非常重要的角色,利用它可能会让你轻松的将性能提升一倍。(你可以通过这里来了解详情,但你应该知道,没有银弹,也没有什么固定的最优值是适合各种不同的环境,这个完全依赖于你的系统负载。因此其默认值跟 MySQL 5.5 一样都是 6)。
因此,在我的测试中,我非常好奇想了解在不同的负载情况下最佳的 AHI 和 Spin Delay 设置的配置对。
接下来要记住 MySQL 5.5 和 5.6 在可伸缩性方面的限制。我在 8、16、32 和 64 核的情况下重新进行测试(64核相当于开启和超线程的32核机器,其他的都没有开启超线程)
首先向你展示第一个有趣的比较,为了跟我以前的测试保持“兼容性”,我首先测试了 TPS (事务/秒),然后再是 QPS (查询/秒) ,我更喜欢这种方式。
首个测试是经典的 Sysbench OLTP_RO (只读):
Sysbench OLTP_RO:
接下来是同一个 OLTP_RO 测试,但在事务中不进行表的打开和关闭操作 (完整的解释请看 这里 )
Sysbench OLTP_RO-trx :
接下来是 "point-selects" ,这是一种读数据的方式,在以前的 MySQL 5.5 版本表现良好,但在 5.6 仍有一些不同。
Sysbench OLTP_RO Point-Selects :
这是最痛苦的测试,Simple-Ranges (你可以阅读 此文 了解为什么痛苦和令人沮丧)
Sysbench OLTP_RO Simple-Ranges :
下面是读写测试,这还不是负载最重的读写,但仍可说明问题:
Sysbench OLTP_RW :
TPS 从 256 个并发用户时就开始下降,期待这个有更高的水平。但仍然比 5.5 版本要高出 2 倍,相信我,下一个版本的 MySQL 表现会更好。这个阶段可通过调整 innodb 线程并发设置来得到更稳定和更高性能。
我很高兴的看到 MySQL 5.6 GA 发布,因为:
这是 MySQL 史上最棒的版本
在高负载下比 MySQL 5.5 快很多
更好的设计
更具可调节性
性能分析更透明
更好的仪表化
这些方式比你以往看到的都要好
包含很多新特性
因此,我唯一的问题是:你什么时候开始测试 MySQL 5.6 并制定数据库移植计划?
MySQL 5.6 GA 发布了,毫无疑问,这是 MySQL 最棒的一个版本。
如果你还不清楚 MySQL 5.6 版本一长串的新特性和改进内容,可以从这里获得了解。
而我这篇文章的主要目的则是性能的测试。
我使用 Sysbench workloads (Read-Only/Read-Write) 来测试。下面是我的测试环境:
硬件配置:
服务器 : 32核 bi-thread (HT) Intel 2300Mhz, 128GB RAM
操作系统 : Oracle Linux 6.2
文件系统 : XFS mounted with "noatime,nodiratime,nobarrier,logbufs=8"
MySQL : 5.6-GA, latest 5.5
MySQL 配置:
#-------------------------------------------------- max_connections = 4000 key_buffer_size = 200M low_priority_updates = 1 sort_buffer_size = 2097152 back_log = 1500 query_cache_type = 0 # files innodb_file_per_table innodb_log_file_size = 1024M innodb_log_files_in_group = 3 innodb_open_files = 4000 table_open_cache = 8000 table_open_cache_instances = 16 # buffers innodb_buffer_pool_size = 32000M innodb_buffer_pool_instances = 32 innodb_log_buffer_size = 64M join_buffer_size = 32K sort_buffer_size = 32K # tune innodb_checksums = 0 innodb_doublewrite = 0 innodb_support_xa = 0 innodb_thread_concurrency = 0 innodb_flush_log_at_trx_commit = 2 innodb_flush_method = O_DIRECT innodb_max_dirty_pages_pct = 50 innodb_use_native_aio =1 innodb_stats_persistent = 1 innodb_spin_wait_delay = 6 / 96 # perf special innodb_adaptive_flushing = 1 innodb_flush_neighbors = 0 innodb_read_io_threads = 16 innodb_write_io_threads = 4 innodb_io_capacity = 2000 innodb_purge_threads =1 innodb_adaptive_hash_index = 1 / 0 # Monitoring innodb_monitor_enable = '%' performance_schema = ON performance_schema_instrument = '%=on' #--------------------------------------------------
MySQL 调整:
配置最主要的不同是 AHI (innodb_adaptive_hash_index) 和 Spin Delay (innodb_spin_wait_delay) -- 而其他的部分在这个测试过程中基本上已经足够好了。
关于 AHI 的影响我之前已经写了很多文章。AHI 主要的困境在于“用还是不用”,在很多情况下它可以帮助因为锁导致的堵塞并加快索引的访问,但在高并发的情况下可能会因为其 btr_search_latch 导致 rw锁争用导致的瓶颈
在 MySQL 5.6 中的 Spin Delay 设置需要特别的注意,因为它在管理内部互斥量和 rw 锁争用时扮演非常重要的角色,利用它可能会让你轻松的将性能提升一倍。(你可以通过这里来了解详情,但你应该知道,没有银弹,也没有什么固定的最优值是适合各种不同的环境,这个完全依赖于你的系统负载。因此其默认值跟 MySQL 5.5 一样都是 6)。
因此,在我的测试中,我非常好奇想了解在不同的负载情况下最佳的 AHI 和 Spin Delay 设置的配置对。
接下来要记住 MySQL 5.5 和 5.6 在可伸缩性方面的限制。我在 8、16、32 和 64 核的情况下重新进行测试(64核相当于开启和超线程的32核机器,其他的都没有开启超线程)
首先向你展示第一个有趣的比较,为了跟我以前的测试保持“兼容性”,我首先测试了 TPS (事务/秒),然后再是 QPS (查询/秒) ,我更喜欢这种方式。
首个测试是经典的 Sysbench OLTP_RO (只读):
Sysbench OLTP_RO:
接下来是同一个 OLTP_RO 测试,但在事务中不进行表的打开和关闭操作 (完整的解释请看 这里 )
Sysbench OLTP_RO-trx :
接下来是 "point-selects" ,这是一种读数据的方式,在以前的 MySQL 5.5 版本表现良好,但在 5.6 仍有一些不同。
Sysbench OLTP_RO Point-Selects :
这是最痛苦的测试,Simple-Ranges (你可以阅读 此文 了解为什么痛苦和令人沮丧)
Sysbench OLTP_RO Simple-Ranges :
下面是读写测试,这还不是负载最重的读写,但仍可说明问题:
Sysbench OLTP_RW :
TPS 从 256 个并发用户时就开始下降,期待这个有更高的水平。但仍然比 5.5 版本要高出 2 倍,相信我,下一个版本的 MySQL 表现会更好。这个阶段可通过调整 innodb 线程并发设置来得到更稳定和更高性能。
我很高兴的看到 MySQL 5.6 GA 发布,因为:
这是 MySQL 史上最棒的版本
在高负载下比 MySQL 5.5 快很多
更好的设计
更具可调节性
性能分析更透明
更好的仪表化
这些方式比你以往看到的都要好
包含很多新特性
因此,我唯一的问题是:你什么时候开始测试 MySQL 5.6 并制定数据库移植计划?
相关文章推荐
- MySQL 性能比较测试:MySQL 5.6 GA -vs- MySQL 5.5
- MySQL性能比较测试:MySQL5.6 GA -VS- MySQL5.5
- MySQL性能比较测试:MySQL5.6 GA -VS- MySQL5.5
- MySQL 性能比较测试:MySQL 5.6 GA -vs- MySQL 5.5
- 优化系列 | MySQL 5.6 vs MariaDB 5.5 vs Percona(5.5 & 5.6) 之TPCC性能测试
- MySQL 5.6 vs MariaDB 5.5 vs Percona(5.5 & 5.6) 之TPCC性能测试
- 优化系列 | MySQL 5.6 vs MariaDB 5.5 vs Percona(5.5 & 5.6) 之TPCC性能测试
- mysql 5.6性能vs mysql 5.5的讨论
- mysql 5.7.15 vs mysql 5.6.31性能测试以及不同linux内核性能比较
- MySQL 5.6 GA 与 MySQL 5.5 性能对比
- Sysbench OLTP 性能测试: MySQL-5.6 vs. MariaDB-10.0
- mysql 5.6性能vs mysql 5.5的讨论
- MySQL 5.6 和 MariaDB-10.0 的性能比较测试
- CUDA(5.5)与MySQL 5.6的rint函数定义冲突引起的VS编译器C2264错误
- MySQL 5.5 分区性能测试之索引使用情况
- HBase 高性能获取数据(多线程批量式解决办法) + MySQL和HBase性能测试比较
- Percona Server与MySQL 5.5的性能比较
- MySQL两种表存储结构MyISAM和InnoDB的性能比较测试
- MariaDB 和 MySQL 性能测试比较
- mysql性能测试及不同版本的比较