數據庫性能測試

 

12月10日，前阿里數據庫團隊資深DBA楊奇龍老師，在【DBA+社羣】北京羣進行了一次主題爲「數據庫性能測試」的線上分享。小編特別整理出其中精華內容，供你們學習交流。同時，也很是感謝楊奇龍老師對DBA+社羣給予的大力支持。

 

嘉賓簡介

 

楊奇龍

• 前阿里數據庫團隊資深DBA

• 主要負責淘寶業務線,經歷屢次11.11，有海量業務訪問DB架構設計經驗。

• 目前就任於有贊科技DBA，負責數據庫運維工做，熟悉MySQL 性能優化，故障診斷，性能壓測,對NoSQL感興趣，但願與你們多多交流，彼此一塊兒成長。

 

內容摘要

 

• 壓測方法論

• 爲何要壓測

• 影響因素

• 統計的指標

• 經常使用的壓測工具

• 合理的壓測平臺

• 參考

 

這個是這次分享的大綱，本次分享其實相對比較簡單，偏向於「紙上談兵」 不涉及具體的實踐操做，沒有介紹工具如何使用 ，更可能是介紹我對MySQL 壓測的認識，總結。有什麼不妥之處，望各位大牛不吝指導。

 

演講實錄

 

1壓測方法論

 

• 壓測目的

• 壓測場景／模型

• 結果分析

• 壓測報告

 

其實能夠把每次壓測看成是一個項目，包括壓測目的是什麼？新版本數據庫上線？新功能？ 新的機型 ？

 

肯定壓測目標以後咱們要選擇何種壓測場景進行壓測，只讀，只寫，讀寫混合？ 觀察壓測過程當中的性能曲線是否知足咱們的指望，而且真對性能出現可重複性抖動的問題進行分析緣由並改進。

 

壓測結束以後，發佈壓測報告。

 

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