| 导语 最近在配合某同事做一项性能压测，发现相同数据量、相同数据库参数、相同sysbench压力、相同数据库版本和sysbench版本、相同服务器硬件环境下，我和同事的压测结果天差
| 导语
最近在配合某同事做一项性能压测，发现相同数据量、相同数据库参数、相同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 即可。
| 作者简介
--结束END--
本文标题: sysbench的lua小改动导致的性能差异
本文链接: https://www.lsjlt.com/news/49933.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
下载Word文档到电脑，方便收藏和打印～
2024-05-15
2024-05-15
2024-05-15
2024-05-15
2024-05-15
2024-05-15
2024-05-15
2024-05-15
2024-05-15
2024-05-15
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
官方手机版
微信公众号
商务合作
0