使用sysbench壓力測試MySQL（一）(r11筆記第3天)

今天用了下新版本的sysbench，發現和早期版本的差別還不小，確實有不少有趣的地方，是的，我們繼續測試下MySQL。

如果大家看過《高效能MySQL》這本書，就會發現裡面對於基準測試的描述非常全面和專業，裡面的測試場景都是基於早期版本，這個版本有一個不太方便的地方就是無法抓取到更細節的資料，只有平均值，所以要不需要定製指令碼，要不就需要更多的測試場景和時間來得到一個報告。

sysbench目前最新的版本是1.0.3，裡面的interval引數確實很贊，也是驅動我嘗試的最大動力，因為能夠得到一個相對實時的資料變化。

sysbench的作者

在MySQL這個圈子裡，Alexey Kopytov 很多人都知道，他是sysbench的作者，而且同時他就職於Percona,曾經在Oracle參與MySQL的研發工作。Percona Server和XtraBackup工具就是他們合理開發的。所以sysbench原生支援MySQL也就顯得順利成章，一個好的工具離不開那些低調的技術牛人。

Alexey Kopytov is a Principal Software Engineer at Percona. Before joining Percona in 2010 he was a member of the MySQL development team at Oracle. His focus at Percona is development of both Percona Server and Percona XtraBackup.

安裝sysbench新版本的坑

安裝sysbench的步驟常規就是四步：

1. 執行autogent.sh指令碼

2. ./configure

3. make

4. make install

但是這樣一個常規的工作在新版本中需要注意一些地方，可能會導致你安裝失敗，比如autoconf的版本需要在2.63以上，RedHat 5的版本中預設是2.59，滿足不了，而且最重要的是如果你使用的版本低於RedHat 6，很可能遇到下面的這種錯誤資訊：

lj_ir.c:64: error: ‘exp2’ undeclared here (not in a function)

lj_ir.c:64: error: ‘log2’ undeclared here (not in a function)

make[3]: *** [lj_ir.o] Error 1如果c功底很紮實，可以trace一把，也可能找到那些過期的設定，做一個遮蔽，我是最後果斷放棄了。一來升級autoconf版本，二來除錯這些邊界問題，最關鍵的RedHat 5竟然預設沒有安裝Lua,這可是新版本中的標配。

所以安裝新版還是直接在RedHat 6以上的版本使用為佳。

如果你使用sysbench丟擲了MySQL連結庫的問題，這個處理相對要常規一些。

# sysbench --test=oltp help

sysbench: error while loading shared libraries: libmysqlclient.so.20: cannot open shared object file: No such file or directory我們可以新增一個軟連結

ln -s /usr/local/mysql/lib/libmysqlclient.so.20 /usr/lib/

如果沒有生效，在ld.so.conf中配置生效即可

新增路徑至/etc/ld.so.conf

ldconfig

Lua的安裝

Lua指令碼是sysbench新版本中的標配，所以你得熟悉下基本的安裝，而且Lua語言相對比較簡潔，原始碼幾百KB,用c開發，非常適合作為一門語言的完整學習捷徑，總體看了下感覺很不錯。

wget -c http://www.lua.org/ftp/lua-5.2.0.tar.gz

解壓後切換到目錄下

make linux

make install

壓力引數前的準備

我們打算測試的MySQL預設的引數如下,如果猛然看看這個配置好像沒有太大的問題，其實有幾個，我們通過效能測試來說明。

port=3306

socket=/home/mysql/s1/s1.sock

server_id=3306

gtid_mode=ON

enforce_gtid_consistency=ON

master_info_repository=TABLE

relay_log_info_repository=TABLE

binlog_checksum=NONE

log_slave_updates=ON

#log_bin=binlog

binlog_format=ROWsysbench中原來的test選項已經失效。

# sysbench --test=oltp help

WARNING: the --test option is deprecated. You can pass a name or path on the command line without any options.我們開啟sysbench的測試，可以使用如下的命令生成資料。

sysbench /home/sysbench/sysbench-1.0.3/src/lua/oltp_read_write.lua --mysql-user=root --mysql-port=3306 --mysql-socket=/home/mysql/s1/s1.sock --mysql-host=localhost --mysql-db=sysbenchtest --tables=10 --table-size=5000000 --threads=30 --events=5000000 --report-interval=5prepare

這裡有幾個地方要提一下，首先新版的sysbench需要指定一個Lua模板，在sysbench安裝目錄下自帶了一批模板,src/lua目錄的檔案如下,我們選擇讀寫的oltp模板。

bulk_insert.lua

internal

Makefile

Makefile.am

Makefile.in

oltp_common.lua

oltp_delete.lua

oltp_insert.lua

oltp_point_select.lua

oltp_read_only.lua

oltp_read_write.lua

oltp_update_index.lua

oltp_update_non_index.lua

oltp_write_only.lua

select_random_points.lua

select_random_ranges.lua

原本的引數

--oltp-test-mode=complex已經失效，

--mysql-table-engine=innodb 選項也不存在

--oltp-num-tables=10 需要改為--tables=10

--oltp-table-size=5000000 需要改為--table-size=5000000

測試場景對比1

對於資料庫是否開啟binlog,開啟前後對於資料庫本身的效能影響到底有多大，這個我一直沒有一個相對清晰的感受，決定逐步來測試一下，我首先設定了執行緒數為30,50,100,150為樣本進行測試。

開啟30個執行緒的測試。，對於50個，100個只需要調整--threads即可。

sysbench /home/sysbench/sysbench-1.0.3/src/lua/oltp_read_write.lua --mysql-user=root --mysql-port=3306 --mysql-socket=/home/mysql/s1/s1.sock --mysql-host=localhost --mysql-db=sysbenchtest --tables=10 --table-size=5000000 --threads=30--report-interval=5 --time=300 run得到的結果類似下面的輸出，每5秒鐘輸出一次，tps,qps這些一目瞭然。

我測試了3分鐘之內（說實話時間有點短）。但是還能看出一些效果。對於執行緒30，執行緒50等的場景測試下，可以看到線上程100~150之間測試結果的資料結果有些不穩定，逐步呈現下降趨勢。

然後我測試了開啟binlog之後的資料。

這個資料可以基本看出執行緒100和執行緒150的TPS差別不大。

而是否開啟binlog的差別在短時間內的比較來看，差別到底有多少？這樣對比來看相對就清晰一些了。左邊是未開啟binlog,右邊是開啟之後的。

通過上面的測試我們可以看到一些瓶頸，而且在後期加壓的時候，發現加不上去了，一個主要原因就在於支援的最大連線數不夠。我們對此做了一個簡單的優化，那就是調節innodb_buffer_pool_size，預設竟然是100多M,支援的連線數是151個。

調整innodb_buffer_pool_size為24G,支援的連線數為3000個，我們繼續測試。

其它條件不變的情況下，TPS可以翻一倍，達到1200~1500，QPS為20000左右。

當然按照這種加壓方式，當加壓測試到執行緒數300就又扛不住了。所以通過這些測試能夠馬上發現很多潛在的問題。

FATAL: mysql_stmt_prepare() failed

FATAL: MySQL error: 1461 "Can't create more than max_prepared_stmt_count statements (current value: 16382)"

FATAL: `thread_init' function failed: /usr/local/share/sysbench/oltp_common.lua:282: SQL API error

FATAL: mysql_stmt_prepare() failed後續進行更多的測試，也會延長時間來得到一個相對更細緻的報告。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-2135370/，如需轉載，請註明出處，否則將追究法律責任。