MySQL的性能基線收集及壓力測試

時間 2020-05-14

標籤 mysql 性能基線收集壓力測試欄目 MySQL 简体版

原文原文鏈接

創建基線的做用：
計算機科學中，基線是項目儲存庫中每一個工件版本在特定時期的一個「快照」。前端

好比咱們如今有併發事物，那麼在某時刻發起一個事物會產生當前數據的快照，那麼這個快照就至關理解爲一個基線，那麼所謂的性能數據的基線就是正常數據收集後的一段時間或者業務數據的負載，將它提供一個正式標準，隨後的工做基於此標準，而且只有通過受權後才能變動這個標準。創建一個初始基線後，之後每次對其進行的變動都將記錄爲一個差值，直到建成下一個基線。node

什麼是基線mysql

1.當前運行狀態記錄、快照，其做用是將其與將來的狀態作對比，那麼將來的時刻產生的關鍵時刻的新狀態則做爲下一次的狀態作對比sql

2.將來時刻產生關鍵事件後的新狀態，做爲下一個基線數據庫

基線收集，需關注的重點centos

1.系統負載
2.MySQL運行狀態緩存

記錄以上兩個重點以便用於優化，好比作一次優化以前先記錄一週的狀態，好比最高、最低、平均等服務器

優化的工做結束以後，咱們再去逐漸觀察，這樣咱們就能知道大概狀況是如何網絡

可是有些時候有些誤區，好比在優化以前tps可能1000 ，優化後可能仍是1000，可是但從tps來看的話可能沒有什麼，可是咱們還須要關注它的iops等信息有所降低，這也是一種優化，因此要多緯度的去對比架構

建議收集基線數據的狀態信息（須要關注的瓶頸）

系統層需關注的信息：

·CPU：%user、%idle、%sys、%iowait #最通用的幾個指標
·IO：tps、await、svctm、%util

·內存：free（free、shared、buffers、cached）、used，以及swap

內存的利用率越多越好，因此咱們主要關注空閒、使用、還有swap ，si so

當前是否使用swap 是否頻繁使用swap 也須要關注

數據庫層需關注的信息：

MySQL：tps、rt、lock、hit ratio、waits

rt = response time
lock = row lock、table lock
hit ratio = cache/buffer hit ratio
waits = Innodb_buffer_pool_wait_free / Innodb_log_waits / Table_locks_waited / Innodb_row_lock_current_waits / Innodb_row_lock_waits

在找瓶頸的時候優先這幾個地方進行分析，針對分析結果再定義優化方案

工做成果量化

所謂的量化，其實無非是對比（相同條件下、相同場景下）

相同條件下：好比說同一套硬件，之前之能跑tps到1000，可是優化後tps能達到5000，這是很大的變化

相同場景下：以前的資源利用率是10% 但優化後降到了5%

相同業務負載下，基線數據產生變化

好比一樣的用戶量一樣的設備，通過優化的以後，tps是下降仍是提高，util、cpu等

相同基線數據狀況下，業務數據發生變化

創建目標，考證方案可行及總結

咱們須要創建一套標準來驗證咱們的方法是否可行
·創建目標
·針對當前基線中存在的瓶頸進行優化
·常見瓶頸以IO爲主（磁盤IO、網絡IO）
·制定相對應的方案，找到優化的嘗試路徑
·CPU：%user、%idle、%sys、%iowait
·IO：tps、await、svctm、%util
·內存：free（free、shared、buffers、cached）、used，以及swap
·MySQL：tps、rt、lock、hit ratio、waits

假設作的優化，針對IO 那麼重點記錄的是io相關的狀況，而後在優化完再判斷util等io相關的數值是否產生了變化

也就是說優化工做是須要針對當前基線數據中的瓶頸進行的，

一般的瓶頸，目前來講仍是磁盤IO和網絡IO

優化IO途徑的建議：

1. 換SSD，PCIE-SSD（提升IO效率，普通SAS盤5000之內的iops，而新設備可達到數萬或者數十萬iops）
2. 少作IO的活（合併屢次讀寫爲一次，或者前端加內存CACHE；或者優化業務，消除IO）
3. 加大內存（更多hot data和dirty data放在內存中，減小物理IO）
4. 調整文件系統爲xfs（相比ext三、ext4提升IOPS能力，高io負載下表現更佳）
5. 調整raid級別爲raid 1+0（相比raid一、raid5等提升IOPS能力）
6. 調整寫cache策略爲wb或force wb（利用陣列卡cache，提升iops）
7. io scheduler（優先使用deadline，若是是SSD，則使用noop

因此咱們想要優化IO（磁盤IO或網絡IO，）的瓶頸，一般是隻要能用錢解決的事情一般就不是事情了，換個設備一般比大量時間花費在優化上要來的強

網絡IO不多，由於一般狀況下mysql的tps實際能達到1-2000算是不錯的，除非用高配服務器，那麼這種狀況下它的網絡交互也不是問題，因此這種狀況下網絡IO通常不會成爲瓶頸，若是是高配的話，通常網卡的性能要提升上去，好比多網卡綁定的方式，或者換成萬兆網卡，正常狀況下千兆網卡就夠了

在找瓶頸的時候優先這幾個地方進行分析，針對分析結果再定義優化方案

通用的優化方案
·CPU：更換更好（將主頻更高一些）、更多核心的CPU（主要看硬件不夠用仍是核心數不夠用，好比頻繁切換cpu）

好比在在多實例的狀況下，最好是有多核心的cpu，另外一種，若是運算任務比較重的話這時咱們還同時須要提升單CPU的運算能力，也就是提升主頻

·IO：更換IOPS性能更高的設備，例如SSD，PCI-E SSD

·內存：增長內存，合理分配

·MySQL服務：升級版本，使用Percona/MariaDB分支版本以支持更高TPS或者下降鎖競爭粒度（主要是下降鎖的力度，將大鎖拆成小鎖，這樣能夠觀測其平衡如何，若是這些小鎖拆分比較好，會帶來比較大的tps的提高，或者個別參數的調整，由於有可能咱們某些參數設置不當而致使tps上不去也是有可能的）

一般狀況下優先升級IO設備，好比硬盤，之前的硬盤用的是7200轉的盤，如今將其更換爲SATA硬盤，或則直接換SSD等；內存也是同樣的，直接加內存便可，這樣能夠有效的利用內存來緩存數據減小IOPS，提升總體TPS

mysql的壓力測試

基準壓力測試目的
·採購新設備，評估新設備性能

拋去設備的新舊架構等，咱們須要對其進行評估新設備的性能

·開發新項目，評估數據庫容量

新項目上線，咱們須要評估新項目存在哪些瓶頸

·新系統上線前，預估/模擬數據庫負載

好比新的操做系統，好比centos7 ，那麼咱們想試一試換成7的話性能與之前的版本的性能差異在哪裏

並且還須要模擬新項目的併發等，咱們須要判斷一下咱們的單臺服務器可否扛住多少，多臺服務器能扛住多少

·更換數據庫版本，評估性能變化

·除了性能，還須要關注可靠性

數據庫運行一段時間是否穩定，是否可持續

若是發現一些異常，好比數據庫不釋放內存等也是很是麻煩的事情，最怕的就是內存溢出

測試模型設計

·明確測試的核心目標、訴求

測試新版本性能/可靠性

測試新系統性能/可靠性

測試新機器性能/可靠性

測試新業務性能

·排除干擾，專一測試目的

不要跑額外的服務，致使性能受到影響

·肯定測試環境

構建一個合理、合適、科學的測試環境，不會和現實環境差距太大，硬件、系統、配置至關

·肯定測試過程當中的衡量和變量

每一次對比測試循環中，只變動少數因素，不要一次性變動太多因素

·保證測試結果的可重複性

保證每一個循環都至少有3次測試，每次持續至少30分鐘，排除最好和最差的測試結果

壓測須要注意事項
·不能只在本地進行壓測

壓力測試工具不能跟數據庫在一塊兒，由於壓力測試工具自己就會產生一些負載，也會產生一些cpu或者消耗一些內存，這樣就不科學，因此建議將其分割開來

·壓測數據量小

內存可能有32G，可是壓力測試數據可能有10G，這樣它會可能將數據所有放在內存裏面，那若是將全部數據放在內存裏

·壓測時間太短

瓶頸剛出現的時候壓測已經結束了，確定是不靠譜的

·壓測模式太少

確定要求有比較複雜的讀寫、隨機讀寫、順序讀寫等分別都要壓力測試

·壓力負載過大或太小

一般須要關注的值：

%user, %iowati, %util, svctm, iops, tps

尤爲是： %user, %iowati, %util, svctm rt（響應時間）不要過大

· 每輪測試完畢要淨化環境，若是有條件的話要將數據從新生成一次，若是沒有條件的話不管如何要清理cache並重啓mysqld：

#清除 OS cache

echo 3 > /proc/sys/vm/drop_caches

service mysqld restart

MySQL測試工具的使用

經常使用測試工具：
·sysbench
Primarily for MySQL OLTP benchmarking，By MySQL AB

老牌測試工具，若是隻作一些cpu測試卻是可使用這個工具，模擬模式以及表的模擬稍微偏簡單一些

主要針對於：cpu、threads、mutex、memory、fileio、oltp

·tpcc-mysql（重點）
Primarily for MySQL OLTP benchmarking，By Percona

·tpch
Primarily for OLAP benchmarking

·tcpcopy
模擬生產環境真實請求

·其餘
mysqlslap
sql-bench

以上工具出現的常見場景：

·fio作專業的IO壓力測試

·用tpcc-mysql作MySQL的OLTP壓力測試

·用tcpcopy作在線壓力模擬測試

好比咱們當前業務每秒的交易數達到一千個，如今想模擬每秒交易數爲一萬個，一種是能夠寫一個腳本進行模擬，另外一種使用tcpcopy將線上用戶的請求引入到某個測試環境下，好比當前有10臺服務器將其所有引到某個服務器上，好比之前有10臺服務器而測試機只有一臺服務器，如今將它所有引到某個測試服務器上，至關於壓力瞬間大了10倍

或者將線上的前端服務器上的請求複製到其餘服務器上而後這些前端服務器將壓力施加到測試服務器上，也是能夠的

使用tpcc-mysql對數據庫作壓力測試

TPC-C是專門針對聯機交易處理系統（OLTP系統）的規範，通常狀況下咱們也把這類系統稱爲業務處理系統。

tpcc-mysql是percona基於TPC-C(下面簡寫成TPCC)衍生出來的產品，專用於MySQL基準測試。其源碼放在launchpad上，用bazaar管理。

下載tppc-mysql

官方下載：
安裝epel源後以便安裝bzr客戶端：

[root@mysql_node1 tools]# wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

[root@mysql_node1 tools]# rpm -ivh epel-release-6-8.noarch.rpm

而後就能夠開始安裝bzr客戶端了：

[root@mysql_node1 tools]# yum install bzr

以後，就能夠開始用bzr客戶端下載tpcc-mysql源碼了

cd /tmp
bzr branch percona-dev/perconatools/tpcc-mysql

或使用中轉下載：

wget http://imysql.com/wp-content/uploads/2014/09/tpcc-mysql-src.tgz

tpcc-mysql的主要工做流程

主要是模擬交易，流程以下：

首先須要訂單--產生支付--倉庫發貨--物流--確認收貨

等相似於電商的過程，而後來模擬高併發來完成一個典型電商的業務

tpcc-mysql的業務邏輯及其相關的幾個表做用以下：
·New-Order：新訂單，主要對應 new_orders 表
·Payment：支付，主要對應 orders、history 表
·Order-Status：訂單狀態，主要對應 orders、order_line 表
·Delivery：發貨，主要對應 order_line 表
·Stock-Level：庫存，主要對應 stock 表

其餘相關表：
·客戶：主要對應 customer 表
·地區：主要對應 district 表
·商品：主要對應 item 表
·倉庫：主要對應 warehouse 表

咱們作的只須要指定倉庫的數量便可，好比一個倉庫支撐多少個區域的用戶等

安裝tpcc-mysql

安裝過程無非就是解壓並執行make 便可

不管是使用源碼包、rpm、二進制包只要能達到目的便可，根據本身須要來進行安裝

[root@mysql_node1 tpcc-mysql]# cd /tmp/

[root@mysql_node1 tmp]# wget http://imysql.com/wp-content/uploads/2014/09/tpcc-mysql-src.tgz

[root@mysql_node1 tmp]# tar xf tpcc-mysql-src.tgz

[root@mysql_node1 tpcc-mysql]# ll

total 36

-rw-r--r--. 1 root root 851 Sep 14 15:05 README

-rw-r--r--. 1 root root 1621 Sep 14 15:05 add_fkey_idx.sql

-rw-r--r--. 1 root root 317 Sep 14 15:05 count.sql

-rw-r--r--. 1 root root 3105 Sep 14 15:05 create_table.sql

-rw-r--r--. 1 root root 763 Sep 14 15:05 drop_cons.sql

-rw-r--r--. 1 root root 477 Sep 14 15:05 load.sh

drwxr-xr-x. 2 root root 4096 Oct 20 15:51 schema2

drwxr-xr-x. 5 root root 4096 Oct 20 15:51 scripts

drwxr-xr-x. 2 root root 4096 Oct 20 15:51 src

[root@mysql_node1 tpcc-mysql]# make

TPCC壓測前的準備

初始化測試庫環境

[root@mysql_node1 tmp]# cd /tmp/tpcc-mysql

[root@mysql_node1 tpcc-mysql]# ls

README add_fkey_idx.sql count.sql create_table.sql drop_cons.sql load.sh schema2 scripts src

建立庫並導入表結構

[root@mysql_node1 tpcc-mysql]# mysqladmin -uroot -p 'mypass' -f create tpcc1000

[root@mysql_node1 tpcc-mysql]# mysql -uroot -pmypass -f tpcc1000 < create_table.sql

初始化完畢後，就能夠開始加載測試數據了
tpcc_load用法以下：

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

或者

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

選項 warehouse 意爲指定測試庫下的倉庫數量。

若是默認不是3306端口的話可使用如下方式：

#因爲是虛機因此這裏先建立30個庫，通常建議在實際生成環境上建立的庫要大於500

[root@node1 tpcc-mysql]# ./tpcc_load 10.12.33.61:3306 tpcc1000 root mypass 30

*************************************

*** ###easy### TPC-C Data Loader ***

*************************************

[server]: 10.12.33.61

[port]: 3306

[DBname]: tpcc1000

[user]: root

[pass]: mypass

[warehouse]: 100

TPCC Data Load Started...

Loading Item

.................................................. 5000

.................................................. 10000

###略####

若是不是使用tcp/ip方式來鏈接數據庫的話，它默認會直接讀取本地mysql.sock文件

因此咱們最好使用ip:prot的方式來鏈接數據庫

500 爲初始化多少個庫的數據量,這裏因爲是虛擬機因此量稍微少一些

進行TPCC測試

tpcc_start 工具用於tpcc壓測，其用法以下

tpcc_start -h server_host -P port -d database_name -u mysql_user -p mysql_password \
-w warehouses -c connections -r warmup_time -l running_time \
-i report_interval -f report_file

參數解釋

-w     指定倉庫數量
-c     指定併發鏈接數
-r     指定開始測試前進行warmup的時間，進行預熱後，測試效果更好
-l     指定測試持續時間
-i     指定生成報告間隔時長
-f     指定生成的報告文件名

-r 指定開始測試前進行warmup的時間，進行預熱後，測試效果更好
-l 指定測試持續時間

一個完整的測試案例

首先在數據庫進行受權

mysql> GRANT ALL ON *.* TO 'root'@'%' IDENTIFIED BY 'mypass';

使用tpcc進行壓測

#因爲是虛機因此這裏先建立30個庫，通常建議在實際生成環境上建立的庫要大於500

#tpcc_start -hlocalhost -d tpcc1000 -u tpcc_user -p "tpcc_password" -w 30 -c 32 -r 120 -l 3600 \

-f tpcc_mysql_20140921.log >> tpcc_caseX_$(date +%F).log 2>&1

將其進行簡化：

[root@node1 tpcc-mysql]# ./tpcc_start -h10.12.33.61 -d tpcc1000 -u root -p 'mypass' -w 30 -c 32 -r 120 -l 1800 >> /tmp/tpcc_caseX_$(date +%F).log 2>&1

以上的意思是隻將結果輸出出來沒有必要將整個過程輸出, 3600 表示1小時

查看輸出的結果

本輪tpcc壓測的一些基本信息
[root@node1 ~]# more /tmp/tpcc_caseX_$(date +%F).log

***************************************

*** ###easy### TPC-C Load Generator ***

***************************************

option h with value '10.12.33.61' #目標主機

option d with value 'tpcc1000' #須要進行壓測的數據庫

option u with value 'root' #用戶名

option p with value 'mypass' #密碼

option w with value '30' #數據庫數量

option c with value '32' #併發線程數量

option r with value '120' #預熱時長

option l with value '1800' #壓測總時長，半小時

[server]: 10.12.33.61

[port]: 3306

[DBname]: tpcc1000

[user]: root

[pass]: mypass

[warehouse]: 30

[connection]: 32

[rampup]: 120 (sec.)

[measure]: 1800 (sec.)

RAMP-UP TIME.(120 sec.)

預熱結束而且開始進行壓測，爲了模擬過程因此縮短了一點

MEASURING START.

#每10秒鐘輸出一次壓測數據

10, 117(104):17.862|21.403, 108(1):4.954|6.161, 10(0):3.733|5.880, 12(0):19.999|41.257, 13(13):19.999|54.707

20, 104(92):14.839|16.684, 106(0):2.932|4.367, 12(0):1.042|1.083, 10(0):15.888|16.643, 12(12):19.999|47.363

30, 94(89):15.864|19.204, 101(0):3.613|4.152, 9(0):0.999|1.039, 9(0):19.232|20.073, 8(8):19.999|40.352

40, 105(89):14.086|15.177, 99(0):3.690|4.408, 9(0):1.180|2.024, 12(0):19.999|21.756, 11(11):19.999|46.144

#############如下略過################

分別表示的意思：

總共6列以逗號進行分隔

-- 第一列，第N次10秒

-- 第二列，總成功執行壓測的次數(總推遲執行壓測的次數):90%事務的響應時間|本輪測試最大響應時間
-- 第三列，新訂單業務成功執行次數(推遲執行次數):90%事務的響應時間|本輪測試最大響應時間
-- 第四列，支付業務的結果，後面幾個的意義同上
-- 第五列，發貨業務的結果，後面幾個的意義同上
-- 第六列，庫存業務的結果，後面幾個的意義同上

#若是超過5毫秒就會發生一次推遲

壓測結束結果解讀

[root@node1 ~]# tail -100 /tmp/tpcc_caseX_$(date +%F).log

找到如下結果信息

[0] sc:1264 lt:14714 rt:0 fl:0 # New-Order，新訂單業務成功(success,簡寫sc)次數，延遲(late,簡寫lt)次數，重試(retry,簡寫rt)次數，失敗(failure,簡寫fl)次數

[1] sc:15834 lt:138 rt:0 fl:0 # Payment，支付業務統計，其餘同上

[2] sc:1580 lt:17 rt:0 fl:0 # Order-Status，訂單狀態業務統計，其餘同上

[3] sc:1598 lt:0 rt:0 fl:0 # Delivery，發貨業務統計，其餘同上

[4] sc:0 lt:1602 rt:0 fl:0 # Stock-Level，庫存業務統計，其餘同上

in 1800 sec.

#一次的採樣結果是不可信的

#如下第二次粗略統計結果，其餘同上