一、测试环境准备
操作系统:centos7.5
处理器:Intel 8核 Current Speed: 2000 MHz, Max Speed: 2000 MHz,三级缓存
内存:16G
磁盘:100G SSD
数据库:mysql 5.6.28
sysbench:1.0.18
二、测试工具
1、sysbench
安装文档: https://github.com/akopytov/sysbench#installing-from-binary-packages
1 | centos7.5使用官方镜像安装 |
帮助:
1 | [root@10-10-135-172 benchmark]# sysbench --help |
2、tpcc-mysql
github: https://github.com/Percona-Lab/tpcc-mysql
1 | mkdir -p /var/lib/mysql/benchmark |
编译完成后,生成 tpcc_load tpcc_start:
三、测试目标
处理器性能
内存性能
磁盘顺序读写,随机读写性能
mysql 吞吐量,响应时间
四、测试步骤
1、准备获取系统性能和状态的脚本
vi /root/benchmark/1-collect-system-status.sh
1 | !/bin/sh |
分析收集到的数据
vi /root/benchmark/2-system-status-analyzer.sh
1 | !/bin/bash |
用法示例
1 | sh 2-system-status-analyzer.sh status_data/5-sec-status-2019-11-19_10-status |
2、使用sysbench服务器性能测试
1)、cpu测试
计算20000个素数。8核cpu,分别测试 1,4,8,12 线程时的 CPU表现
1 | sysbench --test=cpu --threads=1 --cpu-max-prime=20000 run |
1 | sysbench --test=cpu --threads=4 --cpu-max-prime=20000 run |
1 | sysbench --test=cpu --threads=8 --cpu-max-prime=20000 run |
结论:随着线程数增加,计算能力线性增加;
1 | sysbench --test=cpu --threads=12 --cpu-max-prime=20000 run |
结论:当线程数超过cpu核数之后,随着线程数增加,计算能力不再增加,甚至略微下降,这是因为线程上下文切换以后的时间损耗;
2)、文件I/O测试
① 准备30G的数据
1 | sysbench --test=fileio --file-total-size=30G prepare |
② 运行阶段
- seqwr:顺序写入
1 | sysbench --test=fileio --file-test-mode=seqwr --file-total-size=30G --time=60 run |
结论:可以看到,顺序写的过程中 CPU占用很低,但是 buff、cache、block out、in、cs(上下文切换)都很高,这是因为 linux 写磁盘用了 页缓存 和 DMA。
- seqrewr:顺序重写
1 | sysbench --test=fileio --file-test-mode=seqrewr --file-total-size=30G --time=60 run |
- seqrd:顺序读取
1 | sysbench --test=fileio --file-test-mode=seqrd --file-total-size=30G --time=60 run |
- rndrd:随机读取
1 | sysbench --test=fileio --file-test-mode=rndrd --file-total-size=30G --time=60 run |
结论: SSD是没有寻道时间的,但是 随机读(46.95MiB/s) 仍然比顺序读(184.46MiB/s)要慢很多
- rndwr:随机写入
1 | sysbench --test=fileio --file-test-mode=rndwr --file-total-size=30G --time=60 run |
随机写(26.25MiB/s)更慢了,顺序写的速度有138.38MiB/s
- rndrw:混合随机读/写
1 | sysbench --test=fileio --file-test-mode=rndrw --file-total-size=30G --time=60 run |
混合随机读写的速度更是龟速,然而我们平时业务场景中使用最多的就是这种情况,所以一定要注意,能顺序写的,一定不随机写
③ 清除数据
sysbench –test=fileio –file-total-size=30G cleanup
3)、内存测试
测试8K顺序分配
1 | sysbench --test=memory --memory-access-mode=seq --memory-block-size=8K --memory-total-size=100G --threads=12 --events=10000 run |
结论:可以看到 CPU 占用极高,内存写入速度为 10138.32 MiB / sec
测试8K随机分配
1 | sysbench --test=memory --memory-access-mode=rnd --memory-block-size=8K --memory-total-size=100G --threads=12 --events=10000 run |
结论:cpu占用极高,随机分配速度为 1381.41 MiB / sec,只有顺序分配的 1/7 左右,内存都有顺序写都有差距。
3、sysbench对mysql进行OLTP测试
1 | sysbench /usr/share/sysbench/oltp_read_write.lua help |
1) 、新建数据库 sbtest
1 | mysqladmin create sbtest -uroot -p |
2) 、运行状态收集脚本
1 | sh /root/benchmark/1-collect-system-status.sh |
3)、 准备1百万条数据
可以在/usr/share/sysbench/中找到需要使用的lua脚本:
1 | 开始插入数据 |
4)、 运行压测程序
1 | sysbench /usr/share/sysbench/oltp_read_write.lua --threads=64 --time=600 --histogram=on --mysql-host=10.10.135.172 --mysql-port=3306 --mysql-db=sbtest --mysql-user=root --table-size=10000000 run |
总事务数:820388
每秒事务数:1367.22 per sec
总查询数:16407760
每秒查询数:27344.47 per sec
请求分布直方图
1 | [root@10-10-135-172 benchmark]# sysbench /usr/share/sysbench/oltp_read_write.lua --threads=64 --time=600 --histogram=on --mysql-host=10.10.135.172 --mysql-port=3306 --mysql-db=sbtest --mysql-user=root --table-size=10000000 run |
5)、清理数据
1 | sysbench /usr/share/sysbench/oltp_read_write.lua --threads=64 --time=600 --histogram=on --mysql-host=10.10.135.172 --mysql-port=3306 --mysql-db=sbtest --mysql-user=root --table-size=10000000 cleanup |
6)、分析收集到的状态
1 | sh 2-system-status-analyzer.sh status_data/5-sec-status-2019-11-19_06-status > status.txt |
1 | cat status_data/5-sec-status-2019-11-19_06-status | grep 'TS ' > load_status.txt |
4、tpcc-mysql对mysql进行测试
- Build binaries
cd src ; make
( you should have mysql_config available in $PATH)- Load data
- create database
mysqladmin create tpcc1000
- create tables
mysql tpcc1000 < create_table.sql
- create indexes and FK ( this step can be done after loading data)
mysql tpcc1000 < add_fkey_idx.sql
- populate data
- simple step
tpcc_load -h127.0.0.1 -d tpcc1000 -u root -p "" -w 1000
|hostname:port| |dbname| |user| |password| |WAREHOUSES| ref. tpcc_load –help for all options- load data in parallel check load.sh script
- Start benchmark
./tpcc_start -h127.0.0.1 -P3306 -dtpcc1000 -uroot -w1000 -c32 -r10 -l10800
- |hostname| |port| |dbname| |user| |WAREHOUSES| |CONNECTIONS| |WARMUP TIME| |BENCHMARK TIME|
- ref. tpcc_start –help for all options
1)、 创建数据库和表结构
1 | cd tpcc-mysql-master |
2)、加载数据
1 | ./tpcc_load -h10.10.135.172 -P3306 -d tpcc1000 -u root -p 123456 -w 10 |
加载完后查看数据量
1 | select count(*) from tpcc1000.customer; |
3)、运行状态收集脚本
1 | sh /root/benchmark/1-collect-system-status.sh |
4)、执行测试
1 | -w 指定仓库数量 |
top
vmstat 1
执行结果
5)、分析收集到的状态数据
1 | sh 2-system-status-analyzer.sh status_data/5-sec-status-2019-11-19_06-status > status.txt |
vi tpcc_output.txt
1 | *************************************** |
tpcc-mysql的业务逻辑及其相关的几个表作用如下:
- New-Order:新订单,一次完整的订单事务,几乎涉及到全部表
- Payment:支付,主要对应 orders、history 表
- Order-Status:订单状态,主要对应 orders、order_line 表
- Delivery:发货,主要对应 order_line 表
- Stock-Level:库存,主要对应 stock 表
其它表说明:
- 客户:主要对应 customer 表
- 地区:主要对应 district 表
- 商品:主要对应 item 表
- 仓库:主要对应 warehouse 表
6)、清理数据
1 | drop database tpcc1000; |
7)、使用gunplot绘图
① 安装 gunplot
1 | yum install -y gnuplot |
帮助文档: http://gnuplot.info/docs_4.6/gnuplot.pdf
② 准备分析脚本和绘图脚本
gunplot-analyze-tpcc.sh
1 | !/bin/bash |
解释: 把
140, trx: 6365, 95%: 55.992, 99%: 75.599, max_rt: 115.579, 6367|110.699, 637|47.943, 637|156.809, 634|126.359
中的 “[,():|]” 字符去掉以后,就剩下了140 trx 6365 95% 55.992 99% 75.599 max_rt 115.579 6367 110.699 637 47.943 637 156.809 634 126.359
。$1就是140, $5就是55.992,打印的语法就跟c语言一样帮助文档:man awk
③ 对 tpcc-mysql 测试生成的数据文件进行提取
1 | sh gunplot-analyze-tpcc.sh tpcc_output.txt > tpcc_output_transfer.txt |
④ 使用tpcc-graph-build.sh脚本生成图表
- 画95%的事务响应时间图:gunplot-graph-build-rt.sh
1 | !/bin/bash |
- 画间隔时间内完成的事务数的图:gunplot-graph-build-trx.sh
1 | !/bin/bash |
1 | sh gunplot-graph-build-rt.sh tpcc_output_transfer.txt tpcc_output.jpg |
1 | sh gunplot-graph-build-trx.sh tpcc_output_transfer.txt tpcc_output.jpg |
五、mysql性能调优
可以看到tpcc-mysql基准测试中 rt项全部不合格,所以需要对mysql进行性能调优