建立基線的作用：
計算機科學中，基線是項目儲存庫中每個工件版本在特定時期的一個“快照”。

比如我們現在有并發事物，那么在某時刻發起一個事物會產生當前數據的快照，那么這個快照就相當理解為一個基線，那么所謂的性能數據的基線就是正常數據收集后的一段時間或者業務數據的負載，將它提供一個正式標準，隨后的工作基于此標準，并且只有經過授權后才能變更這個標準。建立一個初始基線后，以后每次對其進行的變更都將記錄為一個差值，直到建成下一個基線。

 

什么是基線

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

2.未來時刻產生關鍵事件后的新狀態，作為下一個基線

 

基線收集，需關注的重點

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（相比ext3、ext4提高IOPS能力，高io負載下表現更佳）
5. 調整raid級別為raid 1+0（相比raid1、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  ***

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

<Parameters>

     [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'                  #壓測總時長，半小時

<Parameters>

     [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

 

找到以下結果信息

 

<Raw Results>

  [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.

 

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

 

#以下第二次粗略統計結果，其他同上

<Raw Results2(sum ver.)>

  [0] sc:1264  lt:14714  rt:0  fl:0    

  [1] sc:15835  lt:138  rt:0  fl:0

  [2] sc:1580  lt:17  rt:0  fl:0

  [3] sc:1598  lt:0  rt:0  fl:0

  [4] sc:0  lt:1602  rt:0  fl:0

 

下面所有業務邏輯結果都必須為 OK 才行，如果哪怕有一個不是OK那么久是NG，如果有任何一個結果是NG的話表明本次結果是不能采信的，

 

<Constraint Check> (all must be [OK])

 [transaction percentage]

        Payment: 43.46% (>=43.0%) [OK]      #支付成功次數(上述統計結果中 sc + lt)總成功+延遲的結果 必須大于43.0%，否則結果為NG，而不是OK，所以如果不是大于43%那么結果也是不能采信的

   Order-Status: 4.35% (>= 4.0%) [OK]       #訂單狀態，其他同上

       Delivery: 4.35% (>= 4.0%) [OK]       #發貨

    Stock-Level: 4.36% (>= 4.0%) [OK]       #庫存

 

 [response time (at least 90% passed)]      #響應耗時指標必須超過90%通過才行，所謂的相應時常就是小于5毫秒的測試標準，超過5毫秒肯定是不可以的，如果有10%以上的響應時常說明本次結果不可采信的

#下面幾個響應耗時指標全部 100% 通過才可以，如果低于90%的話，那么肯定是NG ，我這里出現了2個NG

        New-Order: 7.91%  [NG] *           

        Payment: 99.14%   [OK]

        Order-Status: 98.94%  [OK]

        Delivery: 100.00%   [OK]

        Stock-Level: 0.00%  [NG] *

 

<TpmC>

                 532.600 TpmC           # tpmc表示每分鐘的tps