MySQL centos 6 vs 7的性能对比

一前言

计划今年将数据库服务器的os 从centos 6 升级到centos 7,根据惯例,升级之前我们要进行一次性能压测。本文分享一下我们的压测记录和结果。

二 压测准备

2.1 压测方法

使用sysbench-0.5构造10张表 ，每张表500w数据，并行度分别为12 24 36 48 60 72 ，每个并发压测4小时，共计24小时。压测命令如下

/opt/yz-sysbench/bin/sysbench --test=/opt/yz-sysbench/share/sysbench/oltp.lua --oltp-tables-count=10 --oltp-table-size=5000000 - -mysql-db=sysbench --mysql-user=sysbench --mysql-password=sysbench --mysql-socket=/srv/my3306/run/mysql.sock --max-time=14400 --max-requests=0 --num-threads=12 --oltp-test-mod e=complex run

注: sysbench在本地安装，压测几乎没有网络交互的时间损耗。

2.2 目标数据

因为是要压测数据库性能，所以本次主要监控数据库性能qps tps，主机io ，cpu 等性能指标。

三 压测数据

3.1 qps

3.2 insert /delete

sysbench 的oltp模式，insert和delete的比例是一样的，压测每秒的tps数据一致，故放到一起。

3.3 update 性能

3.4 cpu io 对比

centos 7的cpu 负载比centos6 略低，io 利用比centos 6的更高些。

3.5 热点秒杀场景

推荐先看文章热点商品更新优化方案

MySQL为了提高数据库的数据安全性，设置2个参数来控制数据落盘的策略，我们目前的设置为每次提交事务都会出发写数据到磁盘，带来的好处是数据安全，最极端的情况下会丢失一个事务,其负面影响是会导致大量的IO操作。

另外一点数据库并发执行update同一行的动作会被其他已经持有锁的会话堵住，并且需要要进行判断会不会由于自己的加入导致死锁，这个时间复杂度O(n)，如果有1000个请求，每个线程都要检测自己和其他999个线程是否死锁。如果其他线程都没有持有其他锁，约比较50w次(计算方式 999+998+...+1)。这个种锁等待和检查死锁冲突带来巨大的时间成本。

核心优化参数

压测场景:

主要模拟数据库在高并发场景，并发数分别设置为:72,96,144,192,256个活跃会话并发.

在秒杀场景下，centos 7 性能逆天， 同等条件下是centos 6的三倍多 ，通过参数调优之后， centos 7 并发更新可以高达1w以上 ，当然生产环境的商品扣减，有多次查询和insert，update，性能会有一定下降。但是同比而言，也会有相当的性能提升。

3.4 分析

从压测结果上来看 qps centos7 的性能提升明显。qps 提升 20% - 40%。 tps 方面也有 20% 以上的性能提升。期待生产环境下的表现(使用复杂的业务sql，估计性能提升没有sysbench那么明显)。

四 小结

压测新的系统是一件很有意思的事情，centos 7 有哪些影响 MySQL 性能的优化呢？ 这个留个尾巴，且待下回分解。也欢迎生产上已经使用centos 7 或者redhat 7 版本的朋友留言，分享你们遇到的问题或者其他给运维带来的影响。

五 彩蛋

最近开始学习MGR的技术，正好遇到叶金荣老师和之前的老同事冯光普做了一个课程 --《深入浅出MySQL Group Replication》

本课程分成基础、进阶、实践三大模块，系统全面地从基本原理、实现细节、实践指导等多方面学习掌握MGR各个知识点，课程中还介绍了MGR的特性及限制、适用场景、冲突检测原理、流控机制、性能优化等内容。 本课程系业界首发，可通过知数堂在线课堂在线学习。 原价68元，现在报名可享受首月特价仅需48元。

冯老师是某大型电商数据库负责人，保障线上数据库集群的稳定高效运行，并负责数据库自动化运维平台建设，热衷开源数据库技术分享及交流。

扫描下方二维码

点击阅读原文 直达课程