对于很多线上业务而言，如果有新服务器，新的环境，新的业务，到底资源和预期的承载压力是否匹配，这个得用数据说话，或是通过严谨的论证来阐述。
比如一台新的服务器，一般都需要经过压力测试，我们也叫拷机测试。一般都会从多个维度来进行加压（比如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=readrun内存写测试
/usr/local/bin/sysbench --num-threads=10 --max-requests=100 --test=memory --memory-block-size=8k --memory-total-size=32G--memory-oper=writerun而对于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=rndrwprepare
/usr/local/bin/sysbench --file-num=20 --num-threads=20
--test=fileio --file-total-size=
200G--max-requests=1000000 --file-test-mode=rndrwrun
/usr/local/bin/sysbench --file-num=20
--num-threads=20 --test=fileio --file-total-size=
200G--max-requests=1000000 --file-test-mode=rndrwcleanup硬件类的测试，基本一次测试就能够得到一个基线数据，就不需要反反复复测试了。而对于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测试脚本已经写好，会在测试之后共享给大家，这样一来，我可以在瞬间创建出多个节点，然后测试很多复杂的压力场景。到时候我就直接查看数据，得到一个报告，想想都很有意思。