【MySQL】資料庫效能測試

壓測方法論

 

• 壓測目的

• 壓測場景／模型

• 結果分析

• 壓測報告

其實可以把每次壓測當作是一個專案，包括壓測目的是什麼？新版本資料庫上線？新功能？ 新的機型 ？

確定壓測目標之後我們要選擇何種壓測場景進行壓測，只讀，只寫，讀寫混合？ 觀察壓測過程中的效能曲線是否滿足我們的期望，並且真對效能出現可重複性抖動的問題進行分析原因並改進。

壓測結束之後，釋出壓測報告。

2為什麼要壓測

 

• 測試資料庫新版本的效能  

• 測試新機型的效能  

• 驗證某些DB/OS層面的引數  

• 壓測新型儲存的效能 某個廠商的SSD/nVME  

• 壓測某些場景  

• 比如cgroup 隔離 ，網路卡繫結等等

其實這個也就是我們壓測的目的/目標 ，新的db/機器/儲存等上線和新技術預研，業務大促活動類似於11.11 或者秒殺活動等等都是需要提前進行壓測的，評估資料庫系統的效能容量和業務瓶頸，要不訪問量過大導致業務癱瘓 就比較麻煩了，失去客戶對我們產品的信任了。

當然這個需求是對業務量相當大的時候必須做的,如果業務量極小可以忽略該環節。

3影響壓測的因素

 

講完壓測的目的，我們要討論壓測過程中可能會遇到的問題。可能影響整體系統效能的因素大致分為：DB 層面、OS 層面 、儲存層面。

• DB 層面

對於MySQL層面，Buffer pool大小事務寫磁碟，binlog落盤的策略，innodb 層的併發讀設定  事務隔離級別 預設使用rc 都是會影響到最終的壓測寫入效能表現。

• OS 層面

關閉numa 在bios 裡面設定 cpu 為最大效能模式，記得有一兩次是由於設定為省電模式導致效能出現問題。初始化系統的時候選擇ext4 或者xfs 系統檔案。核心引數主要是 tcp 引數，影響業務app 和db之間建立網路連線。

• 儲存層面

其實資料庫模型可以分為 io bond 型別 和cpu bond 型別，估計大家目前的oltp業務系統，絕大多數的業務系統屬於 io bond 型別，大家的業務系統大多數也是都是用了基於 ssd的儲存結構 ，可能採用的raid 模式不一樣有些是raid10 ，有些是raid 5 的差異。

在做效能壓測的時候需要注意 raid 卡的配置，尤其是讀寫策略 WB 模式和WT模式效能差異極大。生產業務上注意對raid卡的充放電，避免導致模式變為WT 模式致使效能下降。

4需要關注的指標

 

• DB層

• QPS ,TPS ,RT(響應時間)

對於db層，我想特別強調對rt的監控，脫離業務場景的壓測都是耍流氓，很多壓測報告都說qps，tps 極高，但是沒有公佈對應的rt。大於生產需求的rt 閥值的壓測結果都是沒有用的。

比如說使用者發起的一個業務請求，包含20次select，10次dml操作，單條sql，rt 為10ms,應用伺服器 和db伺服器網路互動 一次同城1ms -2ms，跨城5-15ms，單獨db的響應時間就30*10=300ms 了，加上app與db的互動和業務處理，前端的處理時間，對於高併發的系統,吞度量不能接受。

• 系統

• CPU: load,usr cpu,

• IO   :  await, svctm, %util  

• 網路:  recv , send

await：從請求磁碟操作到系統完成處理,每次請求的平均消耗時間,包括請求佇列等待時間,單位是毫秒(1秒=1000毫秒)

%iowait：顯示用於等待I/O操作佔用 CPU 總時間的百分比

svctm：平均每次裝置I/O操作的服務時間 (毫秒)%util: 一秒中有百分之多少的時間用於 I/O 操作，或者說一秒中有多少時間 I/O 佇列是非空的

• 工具  

•  orzdba  vmstat  iostat  dstat

5注意事項

 

• 每輪壓測彼此避免相互干擾  

• 使用orzdba 觀察 uckpt％ 等待日誌重新整理完畢之後再開始測試新一輪。  

• 注意壓測系統的瓶頸

我最開始的某些壓測場景沒有做每次壓測的隔離，導致上次的壓測結果影響了下一次的壓測效能，致使系統rt不穩定。可以通過orzdba –innodbs 命令檢視uckpt% 該參數列明還有多少日誌沒有被重新整理到磁碟。

6常用壓測工具(開源)

 

這裡我例舉幾種常見的開源資料庫壓測工具，僅僅講述網上公開的how to 資料有很多，大家可以利用谷歌去搜尋。

• Sysbench

• cpu,threads,mutex,memory,fileio,oltp

sysbench是一款開源的多執行緒效能測試工具，可以執行CPU/記憶體/執行緒/IO/資料庫等方面的效能測試。資料庫目前支援MySQL/Oracle/PostgreSQL。是一款非常受dba 歡迎的壓測工具。

• Tpcc-mysql

• MySQL OLTP benchmarking

TPC(Tracsaction Processing Performance Council) 事務處理效能協會是一個評價大型資料庫系統軟硬體效能的非盈利的組織，TPC-C是TPC協會制定的，用來測試典型的複雜OLTP系統的效能；Tpcc-mysql是percona基於tpcc衍生出來的產品，專用於mysql基準測試，其原始碼放在bazaar上，因此需要先安裝bazaar客戶端。值得說明的是 Tpcc-mysql 包括五個處理邏輯，是比較貼近電商平臺業務的一個壓測工具New-Order :新訂單 Payment :支付 Order-Status :訂單查詢 Delivery:發貨 Stock-Level  :庫存。

• mysqlslap

• MySQL  自帶的壓測工具 單條SQL

mysqlslap是從5.1.4版開始的一個MySQL官方提供的壓力測試工具。通過模擬多個併發客戶端訪問MySQL來執行壓力測試，同時提供了比較詳細的資料效能報告。並且能很好的對比多個儲存引擎在相同環境下的併發壓力效能差別。通過mysqlslap –help可以獲得可用的選項，個人覺得 mysqlslap是所有壓測軟體中最簡單的。

• tcpcopy

• 引用線上流量到測試環境，模擬真實壓力

TCPCOPY 是一個 tcp 流量的實時複製工具，其1.0版本由網易工程師 @tcpcopy 開發和維護。一般用來將生產環境的線上流量實時複製到測試環境進行測試。例如新系統上線前，如果我們希望進行一些基本的壓力測試，那麼我們可以直接利用 tcpcopy 來複制線上的流量過來對系統進行測試，這樣的好處是測試資料接近真實水平，且實施起來相對簡單。下面我們將通過一個真實的使用案例，來簡單介紹 tcpcopy 的基本使用方法。我們假定讀者對 tcp 以及路由相關基本知識有一定了解。

• Mydbtest

• 樓方鑫的一款壓測工具，可以去onexsoft下載

Mydbtest 估計很多人沒有使用過，之前是樓方鑫在支付寶的時候的一個壓測工具，可以根據業務模型 配置業務的sql，利用線上的資料備份進行壓測的一款工具，推薦大家嘗試使用。

7壓測工具

 

• Sysbench  

• 支援多種目標的測試 缺少業務場景支援

• mysqlslap  

• 使用方法簡單，容易上手 測試方法/場景單一 TPCC      優點 業務場景固定，能夠模擬商品購買流程 缺點 不能代表自己公司業務場景。

• tcpcopy  

• 真實的線上壓力,配置複雜，涉及線上環境，風險偏大。

• mydbtest  

• 定製sql,模擬業務訪問，動態修改,需要先部署好壓測目標庫,基礎工作準備略多。

如ppt上所言，每個工具各有千秋，大家在壓測的時候需要選擇最適合自己業務/目的的壓測工具。不過我本人推薦使用mydbtest 工具，其足夠靈活性，適配行更強。

8面臨的問題

 

• 不考慮場景，就是耍流氓

• 難以模擬線上真實業務壓力

• 壓測模式不夠細化  

• 只讀,只寫,RW,會話數,TPCC 能夠模擬五個業務場景

• 不能自動化獲取壓測結果

• 需要人肉處理壓測資料 獲取QPS,TPS 等

9更合理的壓測工具

 

在這裡我提出的是一個設想，運維自動化足夠高的公司可以向這個方向靠近。

• 按需定製壓測計劃

• 模擬線上生產環境

• 配置靈活

• 支援分散式壓測

• 自動收集效能資料

1.1 根據業務需求制定壓測計劃

• 壓測模型

• 模擬各種業務型別 建立訂單，減庫存 等等

1.2 模擬線上生產環境

• 資料庫硬體環境

• 真實的線上資料

• 模擬線上應用行為模式

1.3 工具配置靈活

• 適配多個指令碼

• 調整讀寫比

       讀寫比

       IUD的比例

• 控制併發度

• 調整活躍/非活躍執行緒比例

• 支援分散式

       跨機房呼叫多臺app server

1.4 自動收集效能資料 QPS,TPS,RT

10總結

 

這個是之前和葉金榮討論關於效能壓測的話題之後整理的思維導圖。具體的地址在http://vdisk.weibo.com/s/dCZasgFETrgn/1445265070，涵蓋資料庫壓測的所有內容。當然也有不足之處，歡迎大家給予建議和補充，能夠使資料庫壓測結果更精準 ，為資料庫效能/可用性評估提供有力幫助。

關於參考，這裡我強烈推薦 dimitrik 大牛的blog ，裡面彙集了各種壓測場景和技術分析。

http://dimitrik.free.fr/    
http://blog.itpub.net/22664653/viewspace-713075/
http://blog.itpub.net/22664653/viewspace-757735/
http://blog.itpub.net/22664653/viewspace-757506/
http://imysql.com/2012/12/21/pc-server-benchmarking.html

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