繪圖部分

需要部署gnuplot

yum install -y gnuplot

關(guān)于繪圖相關(guān)腳本的使用

TPCC部分

首先葉總網(wǎng)站上的tpcc指令里面有一個-f生成log的項(xiàng)，說實(shí)話并不知道這個-f生成的log有什么作用，因?yàn)槟壳霸诰W(wǎng)上找到的繪圖工具都無法讀取這個-f生成的數(shù)據(jù)，所以后續(xù)tpcc的命令并未采用-f參數(shù)去生成腳本。

葉總版本里面自帶的analyze.sh在我的測試中顯得不太好使（沒有仔細(xì)看腳本，直接復(fù)制過來了），本次壓測采用的analyze.sh腳本如下

#!/bin/sh

TIMESLOT=1

if [ -n "$2" ]

then

TIMESLOT=$2

fi

cat $1 | grep -v HY000 | grep -v payment | grep -v neword | awk -v timeslot=$TIMESLOT 'BEGIN { FS="[,():]"; s=0; cntr=0; aggr=0 } /MEASURING START/ { s=1} /STOPPING THREADS/ {s=0} /0/ { if (s==1) { cntr++; aggr+=$2; } if ( cntr==timeslot ) { printf ("%d %3d\n",$1,(aggr/timeslot)) ; cntr=0; aggr=0 } }'

tpcc-graph.sh腳本內(nèi)容如下（粘貼時最好去掉加黑的注釋）

#!/bin/bash

gnuplot << EOP

set style line 1 lt 1 lw 3? ? ? ? ? ? ? ? ? ? ? ??

set style line 2 lt 5 lw 3

set style line 3 lt 7 lw 3

set style line 4 lt 9 lw 3????????????????????????#個人理解lt 1 和 lw 3應(yīng)該是線段的參數(shù)，需要有多少條線就set多少條;這里4行的lw都是3，這個3可能是線段的寬度等參數(shù)，而前面的lt 1 5 7 9個人覺得可能和顏色之類的有關(guān)

set terminal png size 960,480? ? ? ? ? ? ?#圖片分辨率

set grid x y

set xlabel "Time(sec)"? ? ? ? ? ? ? ? ? ? ? ? ?#X軸名

set ylabel "Transactions"? ? ? ? ? ? ? ? ? ??#Y軸名

set output "$2"

plot "$1" using 1:2 title "5.7.22 threads=100 buffer_pool=2G" ls 1 with lines,\? ? ? ? ? ? ? ? ? ? #使用第1列和第2列數(shù)據(jù)..標(biāo)題..使用第1條線

? ? "$1" using 3:4 title "5.7.22 threads=100 buffer_pool=4G" ls 2 with lines,\

? ? "$1" using 5:6 title "5.7.22 threads=100 buffer_pool=6G" ls 3 with lines axes x1y1? ? ? ??#使用第5列和第6列數(shù)據(jù)..標(biāo)題..使用第3條線

EOP

通過前期的數(shù)據(jù)觀察，不同并發(fā)數(shù)、log_file、log_buffer等參數(shù)情況下的圖像差距并不明顯，為了讓生成圖像能更直觀的展示測試結(jié)果，選取不同buffer_pool_size作為甄別條件

使用分析腳本分別提取對應(yīng)log中的數(shù)據(jù)

[root@GTID02 tpcc-yejr-mysql]# ./analyze.sh tpcc_2G_bufferpool_100_threads_16M_logbuffer_8G_logsize > 2G.data

[root@GTID02 tpcc-yejr-mysql]# ./analyze.sh tpcc_4G_bufferpool_100_threads_16M_logbuffer_8G_logsize > 4G.data

[root@GTID02 tpcc-yejr-mysql]# ./analyze.sh tpcc_6G_bufferpool_100_threads_16M_logbuffer_8G_logsize > 6G.data

將提取的數(shù)據(jù)匯總

[root@GTID02 tpcc-yejr-mysql]# paste 2G.data 4G.data 6G.data > tpcc.data

使用繪圖腳本作圖

（后面的報錯是一個字體問題，不用理會）

[root@GTID02 tpcc-yejr-mysql]# ./tpcc-graph.sh tpcc.data tpcc.jpg

Could not find/open font when opening font "arial", using internal non-scalable font

生成的tpcc.jpg如下圖

一開始個人覺得這個圖并沒有什么卵用，更偏向于采用最終的評估值來結(jié)合excel折線圖進(jìn)行分析

后來在通過sysbench對不同log_file參數(shù)進(jìn)行測試時發(fā)現(xiàn)gnuplot生成的走勢圖能更直觀的發(fā)現(xiàn)一些折線圖不能很好展現(xiàn)的尖刺情況

sysbench部分

采集tps的腳本

[root@GTID02 sysbench]# cat analyze_tps.sh

#!/bin/bash

cat $1|awk '/10s]/,/1800s]/{print $0}'|awk -F '[' '{print $2}'|awk -F ']' '{print $1,$2}'|awk '{print $1,$5}'|awk -F ',' '{print $1}'|awk -F 's' '{print $1 $2}' > $2

采集qps的腳本

[root@GTID02 sysbench]# cat analyze_qps.sh

#!/bin/bash

cat $1|awk '/10s]/,/1800s]/{print $0}'|awk -F '[' '{print $2}'|awk -F ']' '{print $1,$2}'|awk '{print $1,$7+$9}'|awk -F ',' '{print $1}'|awk -F 's' '{print $1 $2}' > $2

繪圖腳本

[root@GTID02 sysbench]# cat sysbench-graph.sh

#!/bin/bash

gnuplot << EOP

set style line 1 lt 1 lw 3

set style line 2 lt 2 lw 3

set style line 3 lt 3 lw 3

set style line 4 lt 4 lw 3

set style line 5 lt 5 lw 3

set style line 6 lt 6 lw 3

set style line 7 lt 7 lw 3

set terminal png size 960,480

set grid x y

set xlabel "Time(sec)"

set ylabel "TPS"

set output "$2"

plot "$1" using 1:2 title "threads=2" ls 1 with lines,\

? ? "$1" using 3:4 title "threads=100" ls 2 with lines,\

? ? "$1" using 5:6 title "threads=200" ls 3 with lines,\

? ? "$1" using 7:8 title "threads=300" ls 4 with lines,\

? ? "$1" using 9:10 title "threads=500" ls 5 with lines,\

? ? "$1" using 11:12 title "threads=800" ls 6 with lines axes x1y1? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

EOP

針對上面幾個腳本的解釋

首先請?jiān)彵救俗诫u的awk水平...

加黑部分的'/10s]/,/1800s]?這2個參數(shù)是需要根據(jù)實(shí)際情況進(jìn)行更改的，我sysbench采取的是10s計(jì)數(shù)一次，累計(jì)運(yùn)行1800s，所以統(tǒng)計(jì)是從10s開始直到1800s結(jié)束；

其中tps的值在過濾之后位于$5的位置，可以直接取出

而qps沒有這個值，個人的理解是read/s和write/s值之和，所以腳本采取了單純的加法，也就是$7+$9

至于響應(yīng)時間（avg），只有從最后的結(jié)果獲取，并不知道如何獲取實(shí)時的值，因此不存在該腳本，而且在報告里面也沒有這個值的走勢圖

對于繪圖腳本，也就是坐標(biāo)的名字換一下，其他和tpcc的繪圖沒區(qū)別

腳本的使用方法與前面tpcc部分相同，這里就只貼一下history

./analyze_tps.sh 100_threads_6G_buffer_100M_logsize.log log100M.data

./analyze_tps.sh 100_threads_6G_buffer_1G_logsize.log log1G.data

./analyze_tps.sh 100_threads_6G_buffer.log log4G.data

paste log100M.data log1G.data log4G.data > log.data

./sysbench-graph.sh log.data log.jpg

生成的log.jpg如下

##############################################

壓測報告

1.測試環(huán)境

? ? ? ? ?MySQL服務(wù)器IP地址：172.17.100.100

???????? 操作系統(tǒng)：CentOSrelease 6.8 (Final)

???????? CPU：4核

???????? 內(nèi)存：8G

???????? 硬盤：普通SAS硬盤

???????? 基線測試工具：tpcc和sysbench

2.測試方案

TPCC

1. 統(tǒng)計(jì)buffer_pool分別取2G、4G、6G時并發(fā)數(shù)分別取32、100、200、300的TpmC值（log_buffer=16M、log_file=8G）

2. 統(tǒng)計(jì)log_buffer=16M，innodb_buffer_size=6G，Log_file=4G時測試并發(fā)數(shù)分別取32、200、300、400、500、600對應(yīng)的TpmC值

3. 統(tǒng)計(jì)log_file分別取1G、2G、4G、8G時并發(fā)數(shù)為100的TpmC值（log_buffer=16M、buffer_pool=6G）

4. 統(tǒng)計(jì)log_buffer分別取8M、16M、64M、128M時時并發(fā)數(shù)為100的TpmC值（buffer_pool=6G、log_file=4G、8G）

5. 每次測試完成，重啟mysql

Sysbench

1. 統(tǒng)計(jì)buffer_pool分別取4G、6G時，并發(fā)數(shù)分別取2、100、200、300、500、800時的TPS、QPS、響應(yīng)時間（avg）值

2. 統(tǒng)計(jì)buffer_pool為6G，log_buffer為16M，并發(fā)數(shù)為100時log_file分別取100M，1G，4G時的TPS值

3. 每次測試完成，重啟mysql

3.測試結(jié)論

基于TPCC的測試

測試一

測試條件

Log_file=8G，log_buffer=16M時并發(fā)數(shù)分別取32、100、200、300；

測試innodb_buffer_size分別取2G、4G、6G對應(yīng)的TpmC值

測試結(jié)論

當(dāng)log_file=8G，log_buffer=16M時，在并發(fā)數(shù)一定的情況下，TpmC值隨著buffer_pool的增大而增大，當(dāng)buffer_pool值達(dá)到系統(tǒng)內(nèi)存的75%（6G）時，TpmC值達(dá)到最優(yōu)

在buffer_pool值一定的情況下，并發(fā)數(shù)在100時TpmC值接近最大值，但本組測試中除開buffer_pool=4G這一組外，其余2組的TpmC值并沒有隨著并發(fā)數(shù)的增加而出現(xiàn)規(guī)律性的減小

測試二

測試條件

log_buffer=16M，innodb_buffer_size=6G，Log_file=4G時；

測試并發(fā)數(shù)分別取32、200、300、400、500、600對應(yīng)的TpmC值

（當(dāng)并發(fā)數(shù)大于600后，TPCC測試導(dǎo)致數(shù)據(jù)庫變得極易崩潰）

測試結(jié)論

當(dāng)log_file=4G，log_buffer=16M，buffer_pool=6G時，TpmC值隨著并發(fā)數(shù)的不斷增加而逐漸降低

并發(fā)數(shù)在32-300之間時的TpmC值比較接近，當(dāng)并發(fā)數(shù)增長到400以后TpmC值出現(xiàn)了相對明顯的下降

測試三

測試條件

log_buffer=16M，并發(fā)數(shù)=100，innodb_buffer_size=6G時；

測試log_file分別取1G、2G、4G、8G對應(yīng)的TpmC值

測試結(jié)論

當(dāng)buffer_pool，并發(fā)數(shù)，log_buffer這3個參數(shù)值一定時，TpmC值隨著log_file值的增大而增大，當(dāng)log_file值增長到4G以后，TpmC的值趨于平穩(wěn)。

（注：為了加快測試進(jìn)度，此次測試時長由半小時縮減到10分鐘，正式測試仍然以半小時為標(biāo)準(zhǔn)）

測試四

測試條件

并發(fā)數(shù)=100，innodb_buffer_size=6G時；

測試log_file分別取4G、8G，log_buffer分別取8M、16M、64M、128M對應(yīng)的TpmC值

測試結(jié)論

當(dāng)并發(fā)數(shù)、buffer_pool這2個參數(shù)值一定時，log_file取8G時的TpmC值相較于該參數(shù)取4G時要略高一些，但總體差異并不明顯，針對此次TPCC測試推薦將log_file設(shè)置為4G能獲得最佳的TpmC值

在上述3個參數(shù)一致的情況下，無論log_buffer的取值如何對于TpmC值的影響都幾乎可以忽略，本次壓測中使用log_buffer=16M

基于sysbench的測試

測試一

測試條件

buffer_pool分別取4G、6G，Log_file=4G，log_buffer=16M；

測試并發(fā)數(shù)分別取2、100、200、300，500、800時對應(yīng)的TPS、QPS、響應(yīng)時間（avg）值

測試結(jié)論

在log_file，log_buffer，并發(fā)數(shù)這3個條件一定的情況下，TPS和QPS隨著buffer_pool的增大而增大，平均響應(yīng)時間也隨之增加；

在log_file，log_buffer，buffer_pool這3個條件一定的情況下，當(dāng)并發(fā)數(shù)為2時，TPS、QPS、響應(yīng)時間（avg）都處在較低的水平；隨著并發(fā)數(shù)達(dá)到100，TPS、QPS這2個指標(biāo)基本維持在峰值水平，不會隨著并發(fā)數(shù)的增長而產(chǎn)生明顯變化；響應(yīng)時間（avg）則隨著并發(fā)數(shù)的增大而增大。

在測試中發(fā)現(xiàn)并發(fā)數(shù)達(dá)到1200時，無法使用sysbench進(jìn)行正常的測試。

測試二

測試條件

buffer_pool=6G，log_buffer=16M，并發(fā)數(shù)=100；

測試log_file分別取100M、1G、4G時對應(yīng)的TPS值

測試結(jié)論

在buffer_pool，log_buffer，并發(fā)數(shù)這3個條件一定的情況下，當(dāng)log_file≥1G時，TPS值穩(wěn)定在峰值水平；當(dāng)log_file取值為100M時，TPS有較大的波動，表明這個取值在本次sysbench測試中對性能有較大的限制，需要根據(jù)實(shí)際log產(chǎn)生的量重新制定合理的log_file值。

測試總結(jié)

通過使用TPCC和sysbench這2種基線測試工具對配置為4核8G的虛擬機(jī)進(jìn)行壓力測試可以發(fā)現(xiàn)，當(dāng)buffer_pool=6G，log_file=1G，log_buffer=16M，并發(fā)=100時，測試得到最佳性能。在該環(huán)境下

TPS≈1300

QPS≈25000

單次響應(yīng)時間（avg）≈77ms

TpmC≈18000

采用TPCC測試，并發(fā)數(shù)在大于500以后存在使MySQL崩潰的隱患

采用sysbench測試，并發(fā)數(shù)在大于1200以后存在使MySQL崩潰的隱患

參考文檔

http://imysql.com/2014/10/10/tpcc-mysql-full-user-manual.shtml

https://www.hi-linux.com/posts/38534.html