绘图部分

需要部署gnuplot

yum install -y gnuplot

关于绘图相关脚本的使用

TPCC部分

首先叶总网站上的tpcc指令里面有一个-f生成log的项，说实话并不知道这个-f生成的log有什么作用，因为目前在网上找到的绘图工具都无法读取这个-f生成的数据，所以后续tpcc的命令并未采用-f参数去生成脚本。

叶总版本里面自带的analyze.sh在我的测试中显得不太好使（没有仔细看脚本，直接复制过来了），本次压测采用的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脚本内容如下（粘贴时最好去掉加黑的注释）

#!/bin/bash

gnuplot << EOP

set style line 1 lt 1 lw 3                        #个人理解lt 1 和 lw3应该是线段的参数，需要有多少条线就set多少条

set style line 2 lt 5 lw 3

set style line 3 lt 7 lw 3

set style line 4 lt 9 lw 3

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列数据..标题..使用第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列数据..标题..使用第3条线

EOP

通过前期的数据观察，不同并发数、log_file、log_buffer等参数情况下的图像差距并不明显，为了让生成图像能更直观的展示测试结果，选取不同buffer_pool_size作为甄别条件

使用分析脚本分别提取对应log中的数据

[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

将提取的数据汇总

[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如下图

一开始个人觉得这个图并没有什么卵用，更偏向于采用最终的评估值来结合excel折线图进行分析

后来在通过sysbench对不同log_file参数进行测试时发现gnuplot生成的走势图能更直观的发现一些折线图不能很好展现的尖刺情况

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

针对上面几个脚本的解释

首先请原谅本人捉鸡的awk水平...

加黑部分的'/10s]/,/1800s] 这2个参数是需要根据实际情况进行更改的，我sysbench采取的是10s计数一次，累计运行1800s，所以统计是从10s开始直到1800s结束；

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

而qps没有这个值，个人的理解是read/s和write/s值之和，所以脚本采取了单纯的加法，也就是$7+$9

至于响应时间（avg），只有从最后的结果获取，并不知道如何获取实时的值，因此不存在该脚本，而且在报告里面也没有这个值的走势图

对于绘图脚本，也就是坐标的名字换一下，其他和tpcc的绘图没区别

脚本的使用方法与前面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.测试环境

         MySQL服务器IP地址：172.17.100.100

         操作系统：CentOSrelease 6.8 (Final)

         CPU：4核

         内存：8G

         硬盘：普通SAS硬盘

         基线测试工具：tpcc和sysbench

2.测试方案

TPCC

1. 统计buffer_pool分别取2G、4G、6G时并发数分别取32、100、200、300的TpmC值（log_buffer=16M、log_file=8G）

2. 统计log_buffer=16M，innodb_buffer_size=6G，Log_file=4G时测试并发数分别取32、200、300、400、500、600对应的TpmC值

3. 统计log_file分别取1G、2G、4G、8G时并发数为100的TpmC值（log_buffer=16M、buffer_pool=6G）

4. 统计log_buffer分别取8M、16M、64M、128M时时并发数为100的TpmC值（buffer_pool=6G、log_file=4G、8G）

5. 每次测试完成，重启mysql

Sysbench

1. 统计buffer_pool分别取4G、6G时，并发数分别取2、100、200、300、500、800时的TPS、QPS、响应时间（avg）值

2. 统计buffer_pool为6G，log_buffer为16M，并发数为100时log_file分别取100M，1G，4G时的TPS值

3. 每次测试完成，重启mysql

3.测试结论

基于TPCC的测试

测试一

测试条件

Log_file=8G，log_buffer=16M时并发数分别取32、100、200、300；

测试innodb_buffer_size分别取2G、4G、6G对应的TpmC值

测试结论

当log_file=8G，log_buffer=16M时，在并发数一定的情况下，TpmC值随着buffer_pool的增大而增大，当buffer_pool值达到系统内存的75%（6G）时，TpmC值达到最优

在buffer_pool值一定的情况下，并发数在100时TpmC值接近最大值，但本组测试中除开buffer_pool=4G这一组外，其余2组的TpmC值并没有随着并发数的增加而出现规律性的减小

测试二

测试条件

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

测试并发数分别取32、200、300、400、500、600对应的TpmC值

（当并发数大于600后，TPCC测试导致数据库变得极易崩溃）

测试结论

当log_file=4G，log_buffer=16M，buffer_pool=6G时，TpmC值随着并发数的不断增加而逐渐降低

并发数在32-300之间时的TpmC值比较接近，当并发数增长到400以后TpmC值出现了相对明显的下降

测试三

测试条件

log_buffer=16M，并发数=100，innodb_buffer_size=6G时；

测试log_file分别取1G、2G、4G、8G对应的TpmC值

测试结论

当buffer_pool，并发数，log_buffer这3个参数值一定时，TpmC值随着log_file值的增大而增大，当log_file值增长到4G以后，TpmC的值趋于平稳。

（注：为了加快测试进度，此次测试时长由半小时缩减到10分钟，正式测试仍然以半小时为标准）

测试四

测试条件

并发数=100，innodb_buffer_size=6G时；

测试log_file分别取4G、8G，log_buffer分别取8M、16M、64M、128M对应的TpmC值

测试结论

当并发数、buffer_pool这2个参数值一定时，log_file取8G时的TpmC值相较于该参数取4G时要略高一些，但总体差异并不明显，针对此次TPCC测试推荐将log_file设置为4G能获得最佳的TpmC值

在上述3个参数一致的情况下，无论log_buffer的取值如何对于TpmC值的影响都几乎可以忽略，本次压测中使用log_buffer=16M

基于sysbench的测试

测试一

测试条件

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

测试并发数分别取2、100、200、300，500、800时对应的TPS、QPS、响应时间（avg）值

测试结论

在log_file，log_buffer，并发数这3个条件一定的情况下，TPS和QPS随着buffer_pool的增大而增大，平均响应时间也随之增加；

在log_file，log_buffer，buffer_pool这3个条件一定的情况下，当并发数为2时，TPS、QPS、响应时间（avg）都处在较低的水平；随着并发数达到100，TPS、QPS这2个指标基本维持在峰值水平，不会随着并发数的增长而产生明显变化；响应时间（avg）则随着并发数的增大而增大。

在测试中发现并发数达到1200时，无法使用sysbench进行正常的测试。

测试二

测试条件

buffer_pool=6G，log_buffer=16M，并发数=100；

测试log_file分别取100M、1G、4G时对应的TPS值

测试结论

在buffer_pool，log_buffer，并发数这3个条件一定的情况下，当log_file≥1G时，TPS值稳定在峰值水平；当log_file取值为100M时，TPS有较大的波动，表明这个取值在本次sysbench测试中对性能有较大的限制，需要根据实际log产生的量重新制定合理的log_file值。

测试总结

通过使用TPCC和sysbench这2种基线测试工具对配置为4核8G的虚拟机进行压力测试可以发现，当buffer_pool=6G，log_file=1G，log_buffer=16M，并发=100时，测试得到最佳性能。在该环境下

TPS≈1300

QPS≈25000

单次响应时间（avg）≈77ms

TpmC≈18000

采用TPCC测试，并发数在大于500以后存在使MySQL崩溃的隐患

采用sysbench测试，并发数在大于1200以后存在使MySQL崩溃的隐患

参考文档

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

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