最典型的子系統測試就是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