绘图部分
需要部署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
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应该是线段的参数，需要有多少条线就set多少条;这里4行的lw都是3，这个3可能是线段的宽度等参数，而前面的lt 1 5 7 9个人觉得可能和颜色之类的有关
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
