sysbench压测小记（r11笔记第99天）

对于很多线上业务而言，如果有新服务器，新的环境，新的业务，到底资源和预期的承载压力是否匹配，这个得用数据说话，或是通过严谨的论证来阐述。

比如一台新的服务器，一般都需要经过压力测试，我们也叫拷机测试。一般都会从多个维度来进行加压（比如CPU,内存，IO等等），看看服务器是否依旧坚挺，虽然这一点上如果产生了懈怠或者懒惰还是会被轻视，但是从身边的例子来看，还是会测试出一些问题来，如果发现了问题，就避免了后续的很多被动。

sysbench就是这么一个工具，功能非常全面。是一个标准模块化，多线程的基准测试工具。

安装的过程相对比较简单，下载之后参考README文档即可，我就直接略过了。

这个工具能够测试哪些方面呢，我们用命令来说明。

 sysbench --help
。。。
Compiled-in tests:
 fileio - File I/O test
 cpu - CPU performance test
 memory - Memory functions speed test
 threads - Threads subsystem performance test
 mutex - Mutex performance test
 oltp - OLTP test

简单来说就是下面的一些方面。

1、磁盘IO性能 2、CPU运算性能 3、调度程序性能 4、内存分配及传输速度 5、POSIX线程性能 6、数据库性能(OLTP基准测试)

比如测试CPU,如果让我们测试还真没有什么好的思路，看看sysbench是怎么做的，可以使用命令sysbench --test=cpu help得到如下的结果：

cpu options:
  --cpu-max-prime=N      upper limit for primes generator [10000]

可以看到重要的关键字prime,即质数，比如查找小于一千万的最大质数，这个问题还是蛮烧脑的，就让CPU来烧吧，这样运行即可。会启用10个并发线程，最大请求数是100

/usr/local/bin/sysbench --num-threads=10 --max-requests=100 --test=cpu --debug --cpu-max-prime=10000000 run 

有了CPU压测的基本概念，后续的几种解释起来就相对容易一些了。

比如测试内存，可以指定测试范围，如32G,64G根据自己需要来。

比如我们测试32G内存，并发线程数是10个，最大请求数是100，分别从读和写两种测试来做。

内存读测试

/usr/local/bin/sysbench --num-threads=10 --max-requests=100 --test=memory --memory-block-size=8k --memory-total-size=32G --memory-oper=read run

内存写测试

/usr/local/bin/sysbench --num-threads=10 --max-requests=100 --test=memory --memory-block-size=8k --memory-total-size=32G --memory-oper=write run

而对于IO测试而言，是有些区别的，因为会有准备数据（比如写一个临时文件），所以会分成几个阶段，准备阶段，运行阶段，清理阶段。

下面就是一个相对简单的场景，20个文件,每个10GB,随机读写，文件大小总量在200G.

/usr/local/bin/sysbench --file-num=20 --num-threads=20 --test=fileio --file-total-size=200G --max-requests=1000000 --file-test-mode=rndrw prepare /usr/local/bin/sysbench --file-num=20 --num-threads=20 --test=fileio --file-total-size=200G --max-requests=1000000 --file-test-mode=rndrw run /usr/local/bin/sysbench --file-num=20 --num-threads=20 --test=fileio --file-total-size=200G --max-requests=1000000 --file-test-mode=rndrw cleanup

硬件类的测试，基本一次测试就能够得到一个基线数据，就不需要反反复复测试了。而对于DBA还是开发同学而言，更加关注于业务层面，我们会从很多可能的角度和场景去分析权衡，这些sysbench也是支持的，就是oltp选项。

当然sysben对于mysql的支持是原生的，而对于其他的数据oracle,PostgreSQL等数据，需要单独配置。

因为应用测试会产生基础数据，所以也是分为多阶段的。

比如准备基础数据，进行压力测试，最后的统计结果和后期的清理。这里值得说的是，对于较低版本的sysbench而言，还不支持多表参数--oltp_tables_count，准备好基础数据，后面就会开启多线程模式进行模拟压力的测试。比如下面的命令，测试模式complex,并发线程数30,最大请求数5000000 ，表的数据量在一亿。先创建一个测试库sysbenchtest，测试完成之后删除即可。

mysql -uroot -e "create database if not exists sysbenchtest" /usr/local/bin/sysbench --mysql-user=root --test=oltp --mysql-host=localhost --oltp-test-mode=complex --mysql-table-engine=innodb --oltp-table-size=100000000 --mysql-db=sysbenchtest --oltp-table-name=innodb_test --num-threads=30 --max-requests=5000000 prepare /usr/local/bin/sysbench --mysql-user=root --test=oltp --mysql-host=localhost --oltp-test-mode=complex --mysql-table-engine=innodb --oltp-table-size=100000000 --mysql-db=sysbenchtest --oltp-table-name=innodb_test --num-threads=30 --max-requests=5000000 run mysql -uroot -e "drop table if exists sysbenchtest.innodb_test; drop database if exists sysbenchtest"

在一台服务器上我进行了测试，发现1亿左右的数据，数据文件在24G左右。

-rw-r----- 1 mysql mysql 61 Mar 10 11:20 db.opt -rw-r----- 1 mysql mysql 8632 Mar 10 11:20 innodb_test.frm -rw-r----- 1 mysql mysql 24419237888 Mar 10 13:29 innodb_test.ibd 得到的报告如下,可以看到整个过程持续了近3个小时，TPS在455左右，其实还是不高的。

对于压力测试，其实一个蛮不错的想法，就是我指定压测的策略，然后让它去在后台运行，MGR测试脚本已经写好，会在测试之后共享给大家，这样一来，我可以在瞬间创建出多个节点，然后测试很多复杂的压力场景。到时候我就直接查看数据，得到一个报告，想想都很有意思。