雲資料庫MySQL測試的正確姿勢

02-02

這個周末非常地無聊，下載了最新版的sysbench，發現已經被改得面目全非。熟悉的編譯選項、運行參數都跑不通了，最坑爹的是有些版本還要自己到處找lua腳本。從產品經理的角度，我要給所有新版本的sysbench打負分！果然小的開源項目都是作者爽完的衛生紙。嘗試了好幾個版本之後，終於找到一個按部就班就能用的。在這分享給大家，節省點時間就是送錢。

我比較熟悉Linux，以下教程是基於CentOS的：

首先，安裝一些必要的系統工具

sudo su - root
yum install autoconf automake make libtool* unzip mysql mysql-devel -y

其次，下載和編譯安裝sysbench

wget https://github.com/akopytov/sysbench/archive/0.5.zip
unzip 0.5.zip
cd sysbench-0.5
./autogen.sh
./configure
make -j8
make install

再其次，初始化MySQL測試環境

mysql -hXXXX -P3306 -uXXXX -pXXXX
>drop database sbtest;
>create database sbtest;
>exit;
sysbench --num-threads=32 --max-time=60 --max-requests=999999999 --oltp-table-size=1000000 --oltp-tables-count=16 --db-driver=mysql --mysql-table-engine=innodb --test=/root/sysbench-0.5/sysbench/tests/db/oltp.lua --mysql-host=XXXX --mysql-port=3306 --mysql-user=XXXX --mysql-password=XXXX prepare 2>&1 > sysbench.log &

最後，愉快地壓測MySQL

sysbench --num-threads=32 --max-time=60 --max-requests=999999999 --oltp-table-size=1000000 --oltp-tables-count=16 --db-driver=mysql --mysql-table-engine=innodb --test=/root/sysbench-0.5/sysbench/tests/db/oltp.lua --mysql-host=XXXX --mysql-port=3306 --mysql-user=XXXX --mysql-password=XXXX run

上面這個sysbench測試將會在MySQL的sbtest庫裡面創建16個innodb表（sbtest是sysbench test的縮寫，作者跟中國DBA沒仇），每個表的數據量是100萬，總共1600萬數據。這個數據量非常小，MySQL的innodb buffer pool有幾個GB基本就可以cache住大部分數據，所以比較適合壓測CPU。如果想要測試IO性能，可以在初始化階段加大oltp-table-size和oltp-tables-count，讓OLTP測試的目標數據儘可能不被cache。

如果運行順利的話，完事之後會得到如下結果：

nnnnnOLTPn test statistics:
n queries performed:
n read: 1093092
n write: 312312
n other: 156156
n total: 1561560
n transactions: 78078 (1300.79 per sec.)
n read/write requests: 1405404 (23414.22n per sec.)
n other operations: 156156 (2601.58 pern sec.)
n ignored errors: 0 (0.00 per sec.)

n reconnects: 0 (0.00 per sec.)
n General statistics:
n total time: 60.0235s
n total number of events: 78078
n total time taken by eventn execution: 1920.2594s
n response time:
n min: 19.56ms
n avg: 24.59ms
n max: 308.74ms
n approx. 95 percentile: 31.44ms

n Threads fairness:
n events (avg/stddev): 2439.9375/36.86
n execution time (avg/stddev): 60.0081/0.01

如果關注吞吐量，看read/write requests；如果關注響應時間，看response time。在response time一定的情況下，通過增加客戶端的線程數可以提升MySQL吞吐量。

注意，線程數不能比MySQL的CPU數量多太多！否則MySQL將會消耗更多CPU在資源爭搶上，吞吐量反而會下降。上面測試用了32個客戶端線程，應該比較具有普適性。

手癢的同學們可以趕緊買幾個雲資料庫玩玩了，我們下周再見。