sysbench性能测试详解

sysbench的CPU基准测试

最典型的子系统测试就是CPU基准测试。该测试使用64位整数，测试计算素数直到某个最大值所需要的时间。下面的例子将比较两台不同的GNU/Linux服务器上的测试结果。

[ server1~] cat/proc/cpuinfo modelname: AMD Opteron(tm) Processor 246
stepping :1
cpu MHz :1992.857cache size:1024KB

 

在这台服务器上运行如下的测试：

[server1~]sysbench--test=cpu--cpu-max-prime=20000 run
sysbench vo.4.8：multithreaded system evaluation benchmark 
...
Test execution sumaary:total time：121.74045

第二台服务器配置了不同的CPU：

[server2~] cat/proc/cpuinfo 
model name：Intel（R）Xeon（R）CPU51302.00CHz stepping：6
cpu WHz：1995.005

测试结果如下：

[server1~] sysbench--test=cpu--cpu-max-prime=20000 run 
sysbench vo.4.8：multithreaded system evaluation benchmark
Test execution summary:total time：61.8596s

测试的结果简单打印出了计算出素数的时间，很容易进行比较。在上面的测试中，第二台服务器的测试结果显示比第一台快两倍。

sysbench的文件/O基准测试

文件I/O（fileio）基准测试可以测试系统在不同I/O负载下的性能。这对于比较不同的硬盘驱动器、不同的RAID卡、不同的RAID模式，都很有帮助。可以根据测试结果来调整/0子系统。文件VO基准测试模拟了很多InnoDB的I/O特性。 测试的第一步是准备（prepare）阶段，生成测试用到的数据文件，生成的数据文件至少要比内存大。如果文件中的数据能完全放入内存中，则操作系统缓存大部分的数据，导致测试结果无法体现I/O密集型的工作负载。首先通过下面的命令创建一个数据集：

sysbench--test=fileio--file-total-size=150G prepare

这个命令会在当前工作目录下创建测试文件，后续的运行（run）阶段将通过读写这些文件进行测试。

第二步就是运行（run）阶段，针对不同的I/O类型有不同的测试选项： seqwr

顺序写入。 seqrewr

顺序重写。

seqrd

顺序读取。 rndrd

随机读取。 rndwr

随机写入。 rdnrw

混合随机读/写。 下面的命令运行文件I/O混合随机读/写基准测试：

sysbench--test=fileio--file-total-size=15o6--file-test-mode=rndrn/
--init-rng=on--max-time=300--max-requests=0 run

​
结果如下：
sysbench vo.4.8：multithreaded system evaluation benchmark Running the test with following options：Number of threads：1
Initializing random number generator from timer.
Extra file open flags：0128files，1.1719Gb each
150Cb total file size Block size 16kb Number of random requests for random I0：10000
Read/Nrite ratio for conbined random I0 test：1.50
Periodic FSYNC enabled，calling fsync（）each 100 requests.
Calling fsync（）at the end of test，Enabled.
Using synchronous I/0mode Doing random r/w test Threads started！
Time limit exceeded，exiting...
Done.
Operations performed：40260 Read，26840 Write，85785 other =152885 Total Read 629.o6Mb Written 419.38Mb Total transferred 1.0239Cb（3.4948Mb/sec）
223.67 Requests/sec executed Test execution summary：
300.00045
total number of events：67100
total time taken by event execution：254.4601
per-request statistics：min：
0.00005
max：0.56285
approx.95 percentile：0.0099s Threads fairness：events（avg/stddev）：67100.0000/0.00
execution time（avg/stddev）：254.4601/0.00

输出结果中包含了大量的信息。和I/0子系统密切相关的包括每秒请求数和总吞吐量。 在上述例子中，每秒请求数是223.67 Requests/sec，吞吐量是3.4948MB/sec。另外，时间信息也非常有用，尤其是大约95%的时间分布。这些数据对于评估磁盘性能十分有用。 测试完成后，运行清除（cleanup）操作删除第一步生成的测试文件：

sysbench--testafileio--file-total-size=15oc cleanup

sysbench的OLTP基准测试

OLTP基准测试模拟了一个简单的事务处理系统的工作负载。下面的例子使用的是一张 超过百万行记录的表，第一步是先生成这张表：

$sysbench--test=oltp--oltp-table-size=1000000--mysq1-db=test/
-mysql-user=root prepare 

sysbench vo.4.8：multithreaded system evaluation benchmark

No DB drivers specified，using mysql Creating tablesbtest... Creating 1000000 records in table‘sbtest... 生成测试数据只需要上面这条简单的命令即可。接下来可以运行测试，这个例子采用了 8个并发线程，只读模式，测试时长60秒：

$sysbench--test=oltp--oltp-table-size=1000000--mysq1-db=test--mysql-user=root/
-max-time=60--oltp-read-only=on--max-requests=0--nun-threads=8 run 
​

sysbench vo.4.8：multithreaded system evaluation benchmark No DB drivers specified，using mysql WARNING:Preparing of"BEGIN"is unsupported，using emulation
（last message repeated 7 times）
Running the test with following options：Number of threads：8
Doing OLTP test.
Running mixed OLTP test Doing read-only test Using Special distribution（12 iterations，1 pct of values are returned in 75 pct cases）
Using"BECIN"for starting transactions Using auto inc on the id column Threads started！
Time limit exceeded，exiting..…
（last message repeated 7 times）
Done.
OLTP test statistics：queries performed：
179606write：
0
total：
205264
transactions：
12829（213.07 per sec.）
deadlocks：
0（o.oo per sec.）
read/write requests：179606（2982.92 per sec.）
other operations：25658（426.13 per sec.）
Test execution summary：total time：
60.21145
total number of events：12829
total time taken by event execution：480.2086
per-request statistics：max：
1.91065
approx.95 percentile：0.1163s Threads fairness：events（avg/stddev）：1603.6250/70.66
execution time（avg/stddev）：60.0261/0.06

如上所示，结果中包含了相当多的信息。其中最有价值的信息如下：

• 总的事务数。·每秒事务数。

• 时间统计信息（最小、平均、最大响应时间，以及95%百分比响应时间）。

• 线程公平性统计信息（thread-fairmess），用于表示模拟负载的公平性。

这个例子使用的是sysbench的第4版，在SourceForge.net可以下载到这个版本的编译好的可执行文件。也可以从Launchpad下载最新的第5版的源代码自行编译（这是一件简单、有用的事情），这样就可以利用很多新版本的特性，包括可以基于多个表而不是单个表进行测试，可以每隔一定的间隔比如10秒打印出吞吐量和响应的结果。这些指标对于理解系统的行为非常重要。

 

Percona的 TPCC-MySQL测试工具

尽管sysbench的测试很简单，并且结果也具有可比性，但毕竟无法模拟真实的业务压力。相比而言，TPC-C测试则能模拟真实压力。2.5.4节谈到的dbt2是TPC-C的一个很好的实现，但也还有一些不足之处。为了满足很多大型基准测试的需求，本书的作者重新开发了一款新的类TPC-C测试工具，代码放在Launchpad上，可以通过如下地址获取：https://code.launchpad.net/-percona-dev/perconatools/tpcc-mysql，其中包含了一个README文件说明了如何编译。该工具使用很简单，但测试数据中的仓库数量很多，可能需要用到其中的并行数据加载工具来加快准备测试数据集的速度，否则这一步会花费很长时间。 使用这个测试工具，需要创建数据库和表结构、加载数据、执行测试三个步骤。数据库和表结构通过包含在源码中的SQL脚本创建。加载数据通过用C写的pcc_load工具完成，该工具需要自行编译。加载数据需要执行一段时间，并且会产生大量的输出信息（一般都应该将程序输出重定向到文件中，这里尤其应该如此，否则可能丢失滚动的历史信息）。 下面的例子显示了配置过程，创建了一个小型（五个仓库）的测试数据集，数据库名为tpcc5。

$./tpcc_load localhost tpcc5 username p4ssword 5
[server]：localhost
[port]：3306
[DBname]：tpcc5
[user]：username[pass]：p4ssword Twarehousel：nousel；TPCC Data Load Started...
Loading Item
..5000
..10000.…15000
[output snipped for brevity]
Loading Orders for D=10，W=5
..……1000
​
3000
Orders Done.
.…DATA LOADING COMPLETED SUCCESSFULLY.

 

然后，使用tpcc_start工具开始执行基准测试。其同样会产生很多输出信息，还是建议重定向到文件中。下面是一个简单的示例，使用五个线程操作五个仓库，30秒预热时间， 30秒测试时间：

$./tpcc_start localhost tpcc5 username p4ssword 5 5 30 30
[server]：localhost
[port]：3306
[oBname]：tpccs
[user]：username[pass]：p4ssword
[warehouse]：5
[connection]：5
[rampup]：30（sec.）
[measure]：30（sec.）
RAMP-UP TIME.（30 sec.）
MEASURING START.
10，63（0）：0.40，63（0）：0.42，7（0）：0.76，6（0）：2.60，6（0）：0.1720，75（0）：0.40，74（0）：0.62，7（0）：0.04，9（0）：2.38，7（0）：0.7530，83（0）：0.22，84（0）：0.37，9（0）：0.04，7（0）：1.97，9（0）：0.80
STOPPINGTHREADS...
1.New-Order
2.Payment
3.0rder-Status
4.Delivery
5.Stock-Level
<9oth Percentile RT（MaxRT）>
NMew-Order：0.37（1.10）
Payment：0.47（1.24）
Order-Status：0.06（0.96）Delivery：2.43（2.72）
Stock-Level：0.75（0.79）
[0]sc：221 1t：0 rt：0fl：0
[1]sc：221 1t：0 rt:o fl:o
[2]sc：23 lt：0 rt:o fl：0
[3]sc：22 1t:o rt:o fl:o[4]sc：22 1t:o rt:o fl:o in 30 sec.
<Raw Results2（sum ver.）>[o]sc：221 1t:o rt:o fl：0[1]sc：221 lt:o rt:o fl：0
[2]sc：23 lt：0 rt:o fl：0[3]sc：22 1t：0 rt:o fl:o[4]sc：22 1t：0 rt:o fl:o
<Constraint Check>（all must be[ok]）
[transaction percentage]
Payment：43.42%（>=43.0%）[oK]
Order-Status：4.52%（）=4.0%）[ok]
Delivery：4.32%（）=4.0%）[ok]
Stock-Level：4.32%（）=4.0%）[OK]
[response time（at least 9o%passed）]
New-Order：100.00%[0K]
Payment：100.00%[OK]
Order-Status：100.00%[oK]
Delivery：100.00%[oKj Stock-Level：100.00%[oK]
<Tpac）
442.000

 

TpmC最后一行就是测试的结果：每分钟执行完的事务数1。如果紧挨着最后一行前发现有异常结果输出，比如有关于约束检查的信息，那么可以检查一下响应时间的直方图，或者通过其他详细输出信息寻找线素。当然，最好是能使用本章前面提到的一些脚本，这样就可以很容易获得测试执行期间的详细的诊断数据和性能数据。