sysbench的lua小改动导致的性能差异-创新互联
| 导语
最近在配合某同事做一项性能压测，发现相同数据量、相同数据库参数、相同sysbench压力、相同数据库版本和sysbench版本、相同服务器硬件环境下，我和同事的压测结果天差地别：一个小时压测结束后，我的压测结果中出现了高频率周期性阻塞(tps,qps为0)，而同事的压测结果中未出现阻塞(tps,qps从头到尾都比较稳定)。正常情况下，在环境完全相同时，不可能会出现如此巨大的性能差异。但这次，不可能发生的事情它的确发生了。经过复测与排查，终于发现了其中的奥妙。
服务器硬件信息
-
数据库主机
* CPU：72 process
* memory：128G
* 磁盘：某存储 100G
* 网卡：intel 万兆网卡 -
数据库版本：MySQL 5.7.21
-
sysbench版本：1.0.9
-
sysbench主机
* CPU：20 process
* memory：128G
* 磁盘：本地SAS 50G
* 网卡：intel 万兆网卡
| 复测结果数据
先来看看压测结果数据，如下图所示（注：此处只截取了前几十秒的数据进行对比）：
-
我的压测结果（下图可见，明显的周期性tps，qps为0的情况）
-
同事的压测结果（下图可见，tps,qps较为稳定且并未出现阻塞情况）
| 抓取等待事件
看到上文第1节中的结果，如果根据以往的经验、常识来快速判断...估计会懵圈！！当得知同事的测试结果很稳定时，我本能地想：要把等待事件信息拉出来瞧瞧！！下面是我与同事各自在复测时截取的等待事件信息（复测时间为3分钟）（不想仔细看等待事件内容的亲可直接跳至第3节）
operation操作时间统计（每秒查询一次，查询数十次截取时间最长的5次）
使用lua脚本随机生成主键值时：假设当delete操作删除id=1的数据行时，紧接着insert也会使用相同的id=1的主键值。所以高概率会出现innodb重复使用delete数据行所在的页来存放insert数据，在sysbench高并发压力下，大部分的insert数据存储可能只需要在内存中已存在的页内操作即可，无需太多IO操作
不使用lua脚本随机生成的主键值，而是使用表的自增属性生成主键值时：假设当delete操作删除id=1的数据行时，紧接着insert由于是表自增属性自己生成，也就是说几乎不太可能id=1，所以高概率会出现innodb重新申请一个数据页来写入insert数据，在sysbench高并发压力下，大部分的insert数据存储可能需要从磁盘文件中重新申请空间，IO操作较为频繁
至此，我和同事的压测结果有巨大差异的原因大致确定，后续经过反复的验证，也确认了是由于oltp.lua脚本的微小差异导致的。由于我们大多数时候都是使用的本地盘，而本地盘IO延迟低，通常情况下sysbench压测时这点微小的差异容易被忽略。而在此案例中，由于我们测试的环境中使用了某存储设备，相对于本地盘，IO延迟大大增加，进而造成了因为oltp.lua脚本的微小差异而导致最后压测结果的巨大差异。
提示：如果不想改动lua脚本，又想避免主键冲突有办法解决吗？有的，从sysbench 0.5版本开始，新增了一个隐藏选项--mysql-ignore-errors，用于忽略指定的错误，如果要避免主键冲突，指定选项--mysql-ignore-errors=1062 即可。
| 作者简介
罗小波·沃趣科技高级数据库技术专家
IT从业多年，历任运维工程师、高级运维工程师、运维经理、数据库工程师，曾参与版本发布系统、轻量级监控系统、运维管理平台、数据库管理平台的设计与编写，熟悉MySQL体系结构，Innodb存储引擎，喜好专研开源技术，追求完美。
当前题目：sysbench的lua小改动导致的性能差异-创新互联
URL标题：http://6mz.cn/article/jjdpj.html