?

?

楊奇龍

• 前阿里數據庫團隊資深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

?

轉載于:https://www.cnblogs.com/zengkefu/p/5647560.html

總結

以上是生活随笔為你收集整理的数据库性能测试---前阿里数据库团队资深DBA杨奇龙的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。