共计 3314 个字符，预计需要花费 9 分钟才能阅读完成。
如何进行 sysbench 压力测试，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面丸趣 TV 小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。
对于很多线上业务而言，如果有新服务器，新的环境，新的业务，到底资源和预期的承载压力是否匹配，这个得用数据说话，或是通过严谨的论证来阐述。
比如一台新的服务器，一般都需要经过压力测试，我们也叫拷机测试。一般都会从多个维度来进行加压（比如 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 测试脚本已经写好，会在测试之后共享给大家，这样一来，我可以在瞬间创建出多个节点，然后测试很多复杂的压力场景。到时候我就直接查看数据，得到一个报告，想想都很有意思。
看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注丸趣 TV 行业资讯频道，感谢您对丸趣 TV 的支持。
