如何用sysbench做好IO性能测试
sysbench 是一个非常经典的综合性能测试工具，通常都用它来做数据库的性能压测，但也可以用来做cpu，io的性能测试。而对于io测试，不是很推荐sysbench，倒不是说它有错误，工具本身没有任何问题，它的测试方法导致测试的数据会让人有些困惑：性能数据到底是不是这样呢，跟云厂商承诺的性能有关系嘛。一般我们都用fio来进行性能测试，云厂商都推荐用fio进行性能测试，通过fio性能测试，都能轻易达到云厂商承诺的性能。
插曲：关于sysbench的版本，现在主要有0.4.12和1.0.版本。截止2006年sysbench好长时间没有发展，2017年之前都是用旧版本0.4.12（所以网上一搜一大堆文章都是0.4.的教程），然后作者估计修了几个bug，变成0.5版本，然后就跟过去做了告别，从2017重新开发了一个新版本sysbench 1.0.*，这里讲述的性能测试都是用了最新版。
1. sysbench fileio测试言归正传，sysbench怎么做io的性能测试呢，sysbench fileio help,参数如下：
#/usr/local/sysbench_1/bin/sysbench fileio helpsysbench 1.0.9 (using bundled luajit 2.1.0-beta2)fileio options: --file-num=n number of files to create [128] --file-block-size=n block size to use in all io operations [16384] --file-total-size=size total size of files to create [2g] --file-test-mode=string test mode {seqwr, seqrewr, seqrd, rndrd, rndwr, rndrw} --file-io-mode=string file operations mode {sync,async,mmap} [sync] --file-async-backlog=n number of asynchronous operatons to queue per thread [128] --file-extra-flags=string additional flags to use on opening files {sync,dsync,direct} [] --file-fsync-freq=n do fsync() after this number of requests (0 - don't use fsync()) [100] --file-fsync-all[=on|off] do fsync() after each write operation [off] --file-fsync-end[=on|off] do fsync() at the end of test [on] --file-fsync-mode=string which method to use for synchronization {fsync, fdatasync} [fsync] --file-merged-requests=n merge at most this number of io requests if possible (0 - don't merge) [0] --file-rw-ratio=n reads/writes ratio for combined test [1.5]sysbench的性能测试都需要做prepare,run,cleanup这三步，准备数据，跑测试，删除数据。那下面就开始实战：
客户用2c4g的vm,挂载120g的ssd云盘做了性能测试，测试命令如下：
cd /mnt/vdb #一定要到你测试的磁盘目录下执行，否则可能测试系统盘了sysbench fileio --file-total-size=15g --file-test-mode=rndrw --time=300 --max-requests=0 preparesysbench fileio --file-total-size=15g --file-test-mode=rndrw --time=300 --max-requests=0 runsysbench fileio --file-total-size=15g --file-test-mode=rndrw --time=300 --max-requests=0 cleanup结果如下：
file operations: reads/s: 2183.76 writes/s: 1455.84 fsyncs/s: 4658.67throughput: read, mib/s: 34.12 written, mib/s: 22.75general statistics: total time: 300.0030s total number of events: 2489528latency (ms): min: 0.00 avg: 0.12 max: 204.04 95th percentile: 0.35 sum: 298857.30threads fairness: events (avg/stddev): 2489528.0000/0.00 execution time (avg/stddev): 298.8573/0.00随机读写性能好像不咋地，换算iops为(34.12+22.75)*1024/16.384=3554.375，与宣称的5400iops有很大差距。眼尖的人肯定发现只有2个核，去遍历128个文件，好像会降低效率，于是定制file-num去做了系列测试，测试结果如下：
file-num1248163264128
read(mb/s) 57.51 57.3 57.36 57.33 55.12 47.72 41.11 34.12
write(mb/s) 38.34 38.2 38.24 38.22 36.75 31.81 27.4 22.75
明显可以看到，默认测试方法会导致性能下降，文件数设置为1达到最大性能。
那file-num=128与file-num=1的区别是测试文件从128个变成1个，但是总文件大小都是15g，都是随机读写，按理性能应该是一致的，区别是会在多个文件之间切换读写，那么可能会导致中断增加和上下文切换开销增大。通过vmstat命令得到了验证：
file-num=128的vmstat输出是这样的：
file-num=1的vmstat输出是这样的：
从上面两个图可以看出file-num=1的时候上下文切换只有8500左右比file-num=128的时候24800小多了，in（中断）也少太多了。减少了中断和上下文切换开销，吞吐能力显著提升了。
再做了一个实验，同样磁盘大小，改成挂载到8c的vm下，改成8线程进行测试，得到如下数据：
file-num1248163264128
read(mb/s) 253.08 209.86 193.38 159.73 117.98 86.78 67.39 51.98
write(mb/s) 168.72 139.9 128.92 106.49 78.66 57.85 44.93 34.65
可以得出同样的结论，file-num=1可以得到最好的性能，理由如上。
2. 与fio测试的比较单进程下，file-num=1换算到iops为(57.51+38.34)*1024/16.384=5990.625，这好像超过我们的iops设置限定了。通过fio是怎么测得这个iops的呢：
fio -direct=1 -iodepth=128 -rw=randrw -ioengine=libaio -bs=4k -size=1g -numjobs=1 -runtime=1000 -group_reporting -filename=iotest -name=randrw_test通过阅读源代码，发现很多不同：
一个是通过libaio，一个是通过pwrite/pread。libaio的性能是非常强劲的，详情可以参考文章。
即使ioengine=psync，这个engine的读写方法是pread和pwrite，但是整个实现也是不一致的。
fio测试的时候direct=1，就是每次都写入磁盘，而sysbench默认file-fsync-freq=100，也就是完成100次操作才会有一个fsync操作，这种操作涉及系统缓存。
3. 深入一步上节认为操作系统干扰以及io读写方式的差异，造成了测试数据的不一致。深入去研究了下源代码，其实sysbench的作者是提倡用libaio，代码里面大量地运用了宏定义，如：
/* 异步写的截取代码 */#ifdef have_libaio else if (file_io_mode == file_io_mode_async) { /* use asynchronous write */ io_prep_pwrite(&iocb, fd, buf, count, offset); if (file_submit_or_wait(&iocb, file_op_type_write, count, thread_id)) return 0; return count; }#endif那怎么启用这个宏呢，默认就是启用这个宏的。
启用这个宏后，执行sysbench fileio help,会发现有这一项：--file-async-backlog=n number of asynchronous operatons to queue per thread [128]，说明have_libaio这个宏确实生效了。
既然sysbench默认有libaio后，那整个测试方法需要调整：
# --file-extra-flags=direct 文件读写模式改成direct# --file-io-mode=async 确保libaio起效# --file-fsync-freq=0 不需要执行fsyncsysbench fileio --file-total-size=15g --file-test-mode=rndrw --time=300 --max-requests=0 --file-io-mode=async --file-extra-flags=direct --file-num=1 --file-rw-ratio=1 --file-fsync-freq=0 run得到测试结果如下：
对于fio命令也进行了调整，把bs调整成16k，其他不变，还是达到上限5400。测试结果如下：
可以看到sysbench测试的效果与fio的测试效果完全一致！
不过个人还是推荐fio来做io的性能测试。
浅谈双绞线在视频监控系统中的实际应用
共享储能和区块链融合，全面推动区块链赋能企业发展
码垛机器人未来的发展将会以多功能的方向快速发展
高性能电机应用推动汽车工业的发展
路由协议分别有哪些
如何用sysbench做好IO性能测试
Linux Qt 及Arm开发板汉字显示
小米6plus什么时候上市？小米6plus最新消息：小米发飙！比小米6还牛的两部新机小米6plus、红米pro2速速来战
试水新零售 小吉科技联手闪殿打造“天生艺术家”快闪店
工业机器人的结构和组成说明
LCD段码液晶屏的发展优势是什么
希捷酷玩530系列固态硬盘，解锁更高性能水平
物联网在未来将成数字学习产业中不可或缺的部分
温湿度传感器在机房监控产品中应用
模拟基础知识:处理SAR ADC输入驱动难题
直线模组在机械手中的应用
笔记本省电技巧(软硬兼施)
PLC电力载波通信的含义，为何要使用PLC技术
苹果获无线充电专利 可为1米内设备隔空充电
盘点2017年12月物联网产业发生的大事
插曲：关于sysbench的版本，现在主要有0.4.12和1.0.版本。截止2006年sysbench好长时间没有发展，2017年之前都是用旧版本0.4.12（所以网上一搜一大堆文章都是0.4.的教程），然后作者估计修了几个bug，变成0.5版本，然后就跟过去做了告别，从2017重新开发了一个新版本sysbench 1.0.*，这里讲述的性能测试都是用了最新版。
1. sysbench fileio测试言归正传，sysbench怎么做io的性能测试呢，sysbench fileio help,参数如下：
#/usr/local/sysbench_1/bin/sysbench fileio helpsysbench 1.0.9 (using bundled luajit 2.1.0-beta2)fileio options: --file-num=n number of files to create [128] --file-block-size=n block size to use in all io operations [16384] --file-total-size=size total size of files to create [2g] --file-test-mode=string test mode {seqwr, seqrewr, seqrd, rndrd, rndwr, rndrw} --file-io-mode=string file operations mode {sync,async,mmap} [sync] --file-async-backlog=n number of asynchronous operatons to queue per thread [128] --file-extra-flags=string additional flags to use on opening files {sync,dsync,direct} [] --file-fsync-freq=n do fsync() after this number of requests (0 - don't use fsync()) [100] --file-fsync-all[=on|off] do fsync() after each write operation [off] --file-fsync-end[=on|off] do fsync() at the end of test [on] --file-fsync-mode=string which method to use for synchronization {fsync, fdatasync} [fsync] --file-merged-requests=n merge at most this number of io requests if possible (0 - don't merge) [0] --file-rw-ratio=n reads/writes ratio for combined test [1.5]sysbench的性能测试都需要做prepare,run,cleanup这三步，准备数据，跑测试，删除数据。那下面就开始实战：
客户用2c4g的vm,挂载120g的ssd云盘做了性能测试，测试命令如下：
cd /mnt/vdb #一定要到你测试的磁盘目录下执行，否则可能测试系统盘了sysbench fileio --file-total-size=15g --file-test-mode=rndrw --time=300 --max-requests=0 preparesysbench fileio --file-total-size=15g --file-test-mode=rndrw --time=300 --max-requests=0 runsysbench fileio --file-total-size=15g --file-test-mode=rndrw --time=300 --max-requests=0 cleanup结果如下：
file operations: reads/s: 2183.76 writes/s: 1455.84 fsyncs/s: 4658.67throughput: read, mib/s: 34.12 written, mib/s: 22.75general statistics: total time: 300.0030s total number of events: 2489528latency (ms): min: 0.00 avg: 0.12 max: 204.04 95th percentile: 0.35 sum: 298857.30threads fairness: events (avg/stddev): 2489528.0000/0.00 execution time (avg/stddev): 298.8573/0.00随机读写性能好像不咋地，换算iops为(34.12+22.75)*1024/16.384=3554.375，与宣称的5400iops有很大差距。眼尖的人肯定发现只有2个核，去遍历128个文件，好像会降低效率，于是定制file-num去做了系列测试，测试结果如下：
file-num1248163264128
read(mb/s) 57.51 57.3 57.36 57.33 55.12 47.72 41.11 34.12
write(mb/s) 38.34 38.2 38.24 38.22 36.75 31.81 27.4 22.75
明显可以看到，默认测试方法会导致性能下降，文件数设置为1达到最大性能。
那file-num=128与file-num=1的区别是测试文件从128个变成1个，但是总文件大小都是15g，都是随机读写，按理性能应该是一致的，区别是会在多个文件之间切换读写，那么可能会导致中断增加和上下文切换开销增大。通过vmstat命令得到了验证：
file-num=128的vmstat输出是这样的：
file-num=1的vmstat输出是这样的：
从上面两个图可以看出file-num=1的时候上下文切换只有8500左右比file-num=128的时候24800小多了，in（中断）也少太多了。减少了中断和上下文切换开销，吞吐能力显著提升了。
再做了一个实验，同样磁盘大小，改成挂载到8c的vm下，改成8线程进行测试，得到如下数据：
file-num1248163264128
read(mb/s) 253.08 209.86 193.38 159.73 117.98 86.78 67.39 51.98
write(mb/s) 168.72 139.9 128.92 106.49 78.66 57.85 44.93 34.65
可以得出同样的结论，file-num=1可以得到最好的性能，理由如上。
2. 与fio测试的比较单进程下，file-num=1换算到iops为(57.51+38.34)*1024/16.384=5990.625，这好像超过我们的iops设置限定了。通过fio是怎么测得这个iops的呢：
fio -direct=1 -iodepth=128 -rw=randrw -ioengine=libaio -bs=4k -size=1g -numjobs=1 -runtime=1000 -group_reporting -filename=iotest -name=randrw_test通过阅读源代码，发现很多不同：
一个是通过libaio，一个是通过pwrite/pread。libaio的性能是非常强劲的，详情可以参考文章。
即使ioengine=psync，这个engine的读写方法是pread和pwrite，但是整个实现也是不一致的。
fio测试的时候direct=1，就是每次都写入磁盘，而sysbench默认file-fsync-freq=100，也就是完成100次操作才会有一个fsync操作，这种操作涉及系统缓存。
3. 深入一步上节认为操作系统干扰以及io读写方式的差异，造成了测试数据的不一致。深入去研究了下源代码，其实sysbench的作者是提倡用libaio，代码里面大量地运用了宏定义，如：
/* 异步写的截取代码 */#ifdef have_libaio else if (file_io_mode == file_io_mode_async) { /* use asynchronous write */ io_prep_pwrite(&iocb, fd, buf, count, offset); if (file_submit_or_wait(&iocb, file_op_type_write, count, thread_id)) return 0; return count; }#endif那怎么启用这个宏呢，默认就是启用这个宏的。
启用这个宏后，执行sysbench fileio help,会发现有这一项：--file-async-backlog=n number of asynchronous operatons to queue per thread [128]，说明have_libaio这个宏确实生效了。
既然sysbench默认有libaio后，那整个测试方法需要调整：
# --file-extra-flags=direct 文件读写模式改成direct# --file-io-mode=async 确保libaio起效# --file-fsync-freq=0 不需要执行fsyncsysbench fileio --file-total-size=15g --file-test-mode=rndrw --time=300 --max-requests=0 --file-io-mode=async --file-extra-flags=direct --file-num=1 --file-rw-ratio=1 --file-fsync-freq=0 run得到测试结果如下：
对于fio命令也进行了调整，把bs调整成16k，其他不变，还是达到上限5400。测试结果如下：
可以看到sysbench测试的效果与fio的测试效果完全一致！
不过个人还是推荐fio来做io的性能测试。
浅谈双绞线在视频监控系统中的实际应用
共享储能和区块链融合，全面推动区块链赋能企业发展
码垛机器人未来的发展将会以多功能的方向快速发展
高性能电机应用推动汽车工业的发展
路由协议分别有哪些
如何用sysbench做好IO性能测试
Linux Qt 及Arm开发板汉字显示
小米6plus什么时候上市？小米6plus最新消息：小米发飙！比小米6还牛的两部新机小米6plus、红米pro2速速来战
试水新零售 小吉科技联手闪殿打造“天生艺术家”快闪店
工业机器人的结构和组成说明
LCD段码液晶屏的发展优势是什么
希捷酷玩530系列固态硬盘，解锁更高性能水平
物联网在未来将成数字学习产业中不可或缺的部分
温湿度传感器在机房监控产品中应用
模拟基础知识:处理SAR ADC输入驱动难题
直线模组在机械手中的应用
笔记本省电技巧(软硬兼施)
PLC电力载波通信的含义，为何要使用PLC技术
苹果获无线充电专利 可为1米内设备隔空充电
盘点2017年12月物联网产业发生的大事