老葉倡議：MySQL壓力測試基準值

通常，我們會出于以下幾個目的對MySQL進行壓力測試：

1、确認新的MySQL版本性能相比之前差異多大，比如從5.6變成5.7，或者從官方版本改成Percona分支版本；

2、确認新的伺服器性能是否更高，能高多少，比如CPU更新了、陣列卡cache加大了、從機械盤換成SSD盤了；

3、确認一些新的參數調整後，對性能影響多少，比如 innodb_flush_log_at_trx_commit、sync_binlog 等參數；

4、确認即将上線的新業務對MySQL負載影響多少，是否能承載得住，是否需要對伺服器進行擴容或更新配置；

針對上面這幾種壓測的目的，相應的測試方法也有所不同。

先說第四種，需要和線上業務結合起來，這時候就需要自行開發測試工具，或者利用 tcpcopy 将線上實際使用者請求導向測試環境，進行仿真模拟測試。

對于前三種，我們通常采用基準測試就可以。比較常用的MySQL基準壓力測試工具有 tpcc-mysql、sysbench、mysqlslap 等幾個。

關于壓力測試工具的使用，可以檢視我之前在ORACLE技術嘉年華上的分享：MySQL壓力測試經驗，在這裡不再細說。

基于促進同行間的交流，統一MySQL壓測标準，并且可以互相分享、對比、借鑒測試結果的目的。是以老葉特别發起MySQL壓力測試基準值倡議。建議大家采用以下幾種壓力測試基準值。

• 

• 倡議：MySQL壓力測試建議基準值(2015試行版）

也可以通路老葉網站（

http://imysql.com

）檢視本文附件excel文檔：壓力測試基準建議及資料采集模闆，裡面已附帶了壓力測試相關的資料采集點建議，壓測結果整理及自動生成對比圖表。歡迎各位同行拍磚提出不同的見解和補充意見，先謝過大家。

關于壓力測試的其他幾個方面：

1、如何避免壓測時受到緩存的影響

【老葉建議】有2點建議

a、填充測試資料比實體記憶體還要大，至少超過 innodb_buffer_pool_size 值，不能将資料全部裝載到記憶體中，除非你的本意就想測試全記憶體狀态下的MySQL性能。

b、每輪測試完成後，都重新開機mysqld執行個體，并且用下面的方法删除系統cache，釋放swap（如果用到了swap的話），甚至可以重新開機整個OS。

[[email protected]]# sync  -- 将髒資料重新整理到磁盤

[[email protected]]# echo 3 > /proc/sys/vm/drop_cache  -- 清除OS Cache

[[email protected]]# swapoff -a && swapon -a

2、如何盡可能展現線上業務真實特點

a、其實上面已經說過了，就是自行開發測試工具或者利用 tcpcopy（或類似交換機的mirror功能） 将線上實際使用者請求導向測試環境，進行仿真模拟測試。

b、利用 http_load 或 siege 工具模拟真實的使用者請求URL進行壓力測試，這方面我不是太專業，可以請教企業内部的壓力測試同僚。

3、壓測結果如何解讀

【老葉建議】壓測結果除了tps/TpmC名額外，還應該關注壓測期間的系統負載資料，尤其是 iops、iowait、svcmtm、%util、每秒I/O位元組數(I/O吞吐)、事務響應時間(tpcc-mysql/sysbench 列印的測試記錄中均有)。另外，如果I/O裝置能提供裝置級 IOPS、讀寫延時 資料的話，也應該一并關注。

加入兩次測試的tps/TpmC結果一樣的話，那麼誰的 事務響應時間、iowait、svctm、%util、讀寫延時 更低，就表示那個測試模式有更高的性能提升空間。

4、如何加快tpcc_load加載資料的效率

【老葉建議】tpcc_load其實是可以并行加載的，一方面是可以區分 ITEMS、WAREHOUSE、CUSTOMER、ORDERS 四個次元的資料并行加載。

另外，比如最終想加載1000個 warehouse的話，也可以分開成1000個并發并行加載的。看下 tpcc_load 工具的參數就知道了：

usage: tpcc_load [server] [DB] [user] [pass] [warehouse]

OR

tpcc_load [server] [DB] [user] [pass] [warehouse] [part] [min_wh] [max_wh]

* [part]: 1=ITEMS 2=WAREHOUSE 3=CUSTOMER 4=ORDERS

本來想自己寫個并行加載腳本的，後來發現萬能的github上已經有人做好了，我就直接拿來用了，這是項目連結 tpcc_load_parallel.sh，加載效率至少提升10倍以上。