新手和专家都必须要掌握的基准测试，你了解多少
本帖最后由 测试积点老人 于 2020-9-27 11:30 编辑基准测试是MySQL新手和专家都必须要掌握地一项基本技能。基准测试是针对系统设计的一种压力测试。通常的目标是为了掌握系统的行为。
基准测试的策略
基准测试有两种主要的策略：一是针对整个系统的整体测试，另外是单独测试MySQL。这两种测试也被称为集成式以及单组件式基准测试。针对整个系统做集成式测试而不是单独测试MySQL的原因有以下几点：
测试整个应用系统，包括web服务器、应用代码、网络和数据库是非常有用的，因为用户关注的并不是MySQL本身的性能，而是应用整体的性能。
MySQL并非总是应用的瓶颈，通过整体的测试可以揭示这一点。
只有对应用做整体测试，才能发现各部分之间的缓存带来的影响。
整体应用的集成式测试更能揭示应用的真实表现，而单独组件的测试很难做到这一点。
有时候不需要了解整个应用的情况，而只需要关注MySQL的性能，至少在项目初期可以 这样做。基于以下情况，可以选择只测试MySQL
需要比较不同的schema或查询的性能
针对应用中某个具体的测试
为了避免漫长的基准测试，可以通过一个短期的基准测试，做快速的"周期循环"，来检测某些调整后的效果
测试何种指标
考虑以下指标，看看如何满足测试的需求：
吞吐量
吞吐量指的是单位时间内的事务处理数。这一直是经典的数据库应用测试指标。这类基准测试主要针对在线事务处理OLTP的吞吐量，非常适用于多用户的交互式应用。常见的测试单位是每秒事务数，有些也采用每分钟事务数。
响应时间或者延迟
这个指标用于测试任务所需的整体时间。根据具体的应用，测试的时间单位可能是微秒、毫秒、秒或者分钟。根据不同的时间单位可以计算出平均响应时间、最小响应时间、最大响应时间和所占百分比。最大响应时间意义不大，因为测试时间越长，最大响应时间也可能越大。而且其结果通常不可重复，每次测试都可能获得不同的最大响应时间。因此，通常可以使用百分比响应时间来代替最大响应时间。例如，如果95%的响应时间都是5毫秒，则表示任务在95%的时间段内都可以在5毫秒内完成。
并发性
并发性是一个非常重要又经常被误解和误用的指标。例如，它经常被表示成多少用户在同一时间浏览一个web站点，经常使用的指标是有多少个会话。然而，HTTP协议是无状态的，大多数用户只是简单地读取浏览器上显式地信息，这并不等于web服务器的并发性。而且web服务器的并发性也不等同于数据库的并发性，而仅仅只表示会话存储机制可以处理多少数据的能力。web服务器的并发性更准确的度量指标，应该是任意时间内有多少同时发生的并发请求。
在应用的不同缓解都可以测量相应的并发性。web服务器的高并发，一般也会导致数据库的高并发，但服务器采用的语言和工具集对此都会有影响。注意不要将创建数据库连接和并发性搞混淆。一个设计良好的应用，同时可以打开成百上千个MySQL数据库服务器连接，但可能同时只有少数连接在执行查询。所以说一个web站点"同时有50000个用户"访问，却可能只有10-15个并发请求到MySQL数据库
换句话说，并发性基准测试需要关注的是正在工作中的并发操作，或者是同时工作中的线程数或者连接数。当并发增加，需要测量吞吐量是否下降，响应时间是否变长，如果是这样，应用可能就无法处理峰值压力。
并发性测试通常不是为了测试应用能达到的并发度，而是为了测试应用在不同并发下的性能。可以通过sysbench指定32、64或者128个线程的测试，然后在测试期间记录MySQL数据库的Threads_running状态值。
可扩展性
在系统的业务压力可能发生变化的情况下，测试可扩展性就非常必要了。可扩展性指的是，给系统增加一倍的工作，在理想情况下就能获得两倍的结果(即吞吐量增加一倍)。或者说，给系统增加一倍的资源就可以获得两倍的吞吐量。同时性能也必须在可以接收的范围内。大多数系统是无法做到如此理想的线性扩展的。随着压力的变化，吞吐量和性能都可能越来越差。
可扩展性指标对于容量规范非常有用，它可以提供其他测试无法提供的信息，来帮助发现应用的瓶颈。
归根结底，应该测试那些对用户来说最重要的指标。因此应该尽可能地去收集一些需求，比如，什么样地响应时间是可以接受的，期待多少的并发性，等等。然后基于这些需求来设计基准测试，避免目光短浅地只关注部分指标，而忽略其他指标。
sysbench
sysbench可以执行多种类型的基准测试，它不仅设计用来测试数据库的性能，也可以测试运行数据库的服务器的性能。
sysbench的基本语法
sysbench ... 命令
command是sysbench要执行的命令，包括prepare，run和cleanup，顾名思义，prepare是为测试预先准备数据，run是执行正式的测试，cleanup是在测试完成后对数据库进行清理。
测试名
testname指定了要进行的测试，在老版本的sysbench中，可以通过–test参数指定测试的脚本；而在新版本中，–test参数已经声明为废弃，可以不使用–test，或者直接指定脚本。
例如，如下两种方法效果是一样的：
sysbench --test=/usr/share/sysbbench/tests/include/oltp_legacy/oltp.lua sysbench /usr/share/sysbbench/tests/include yum安装的sysbench的测试脚本默认在/usr/share/sysbench下面及其下面的文件夹
选项
sysbench的参数有很多，其中常见的包括
--mysql-host：MySQL服务器主机名，默认localhost；如果在本机上使用localhost报错，提示无法连接MySQL服务器，改成本机的IP地址应该就可以了。
--mysql-port：MySQL服务器端口，默认3306
--mysql-user：用户名
--mysql-password：密码
--mysql-db=test 在test这个数据库进行测试，默认sbtest
--mysql-socket=/data/mysql/datanode1/node1.soc 指定socketMySQL执行参数
--oltp-test-mode：执行模式，包括simple、nontrx和complex，默认是complex。simple模式下只测试简单的查询；nontrx不仅测试查询，还测试插入更新等，但是不使用事务；complex模式下测试最全面，会测试增删改查，而且会使用事务。可以根据自己的需要选择测试模式。
--oltp-tables-count：测试的表数量，根据实际情况选择
--oltp-table-size：测试的表的大小，根据实际情况选择
--oltp-read-olny=off读写混合
--threads：客户端的并发连接数
--time：测试执行的时间，单位是秒，该值不要太短，可以选择120
--report-interval：生成报告的时间间隔，单位是秒，如10
--max-requests=0 设置最大请求，0为不限制，想多少请求都可以，在限定的时间内
--percentile=99 去签名99%的数据进行分析 sysbench的CPU基准测试
服务器的CPU配置如下
@cy ~]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family: 6
model : 79
model name: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
stepping : 1
microcode : 0x1
cpu MHz : 2394.456
cache size: 35840 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid: 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes在这台服务器上运行如下的测试
# sysbench --test=cpu --cpu-max-prime=20000 run
Threads started!
CPU speed:
events per second: 295.01
General statistics:
total time: 10.0008s
total number of events: 2951
Latency (ms):
min: 3.27
avg: 3.39
max: 11.17
95th percentile: 3.55
sum: 9994.76
Threads fairness:
events (avg/stddev): 2951.0000/0.00
execution time (avg/stddev): 9.9948/0.00第二台服务器配置
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family: 6
model : 85
model name: Intel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz
stepping : 7
microcode : 0x1
cpu MHz : 2500.002
cache size: 36608 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid: 0
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes 执行测试
# sysbench --test=cpu --cpu-max-prime=20000 run
CPU speed:
events per second: 343.75
General statistics:
total time: 10.0024s
total number of events: 3439
Latency (ms):
min: 2.78
avg: 2.91
max: 23.83
95th percentile: 2.97
sum: 9999.19
Threads fairness:
events (avg/stddev): 3439.0000/0.00
execution time (avg/stddev): 9.9992/0.00可以看到CPU运行速度第二台服务器比第一台要快
sysbench的文件IO测试
文件IO基准测试可以测试系统在不同IO负载下的性能。这对于比较不同的磁盘驱动器、RAID卡、不同的RAID模式，都很有帮助。可以根据测试结果来调整IO子系统。文件IO基准测试模拟了很多InnoDB的IO特性
测试第一步是准备阶段，生成测试用到的数据文件，生成的数据文件至少比内存大。如果文件中的数据能完全放入内存中，则操作系统缓存大部分的数据，导致测试结果无法体现IO密集型的工作负载
首先创建一个数据集
# sysbench --test=fileio --file-total-size=30G prepare这个命令会在当前工作目录下创建测试文件，后续的运行阶段将通过读写这些文件进行测试
针对不同的IO类型有不同的测试选项
seqwr：顺序写入
seqrewr：顺序重写
seqrd：顺序读取
rndrd：随机读取
rndwr：随机写入
rdnrw：混合随机读/写
下面的命令运行文件IO混合随机读/写基准测试
# sysbench --test=fileio --file-total-size=30G --file-test-mode=rndrw --max-time=300 --max-requests=0 run 得到的结果
File operations:
reads/s: 902.00
writes/s: 601.34
fsyncs/s: 1924.64
Throughput:
read, MiB/s: 14.09
written, MiB/s: 9.40
General statistics:
total time: 300.0067s
total number of events: 1028295
Latency (ms):
min: 0.00
avg: 0.29
max: 1949.82
95th percentile: 0.73
sum: 298892.25
Threads fairness:
events (avg/stddev): 1028295.0000/0.00
execution time (avg/stddev): 298.8922/0.00测试完成后，运行清除操作，删除第一步生成的测试文件
# sysbench --test=fileio --file-total-size=30G cleanupsysbench MySQL基准测试
生成3张表，每个表插入100000条数据
# sysbench/usr/share/sysbench/tests/include/oltp_legacy/oltp.lua --table_size=100000 --threads=20 --oltp-tables-count=3--mysql-db=test --mysql-user=root --mysql-host=106.13.177.139 --mysql-password=123.com prepare数据测试
sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua --oltp-table-size=100000 --oltp-tables-count=3 --mysql-db=test --mysql-user=root --mysql-host=106.13.177.139 --mysql-password=123.com --time=60 --max-requests=0 --threads=8 --report-interval=10 run--threads=8 //线程数为8
--time=60 //测试时间为60s
--report-interval=10 //报告打印周期为10s，每10s打印一次
--oltp-read-only=off //非只读操作测试
测试结果
[ 10s ] thds: 8 tps: 92.57 qps: 1896.81 (r/w/o: 1332.89/119.86/444.06) lat (ms,95%): 253.35 err/s: 1.90 reconn/s: 0.00
[ 20s ] thds: 8 tps: 23.90 qps: 477.92 (r/w/o: 334.41/38.90/104.60) lat (ms,95%): 893.56 err/s: 0.00 reconn/s: 0.00
[ 30s ] thds: 8 tps: 24.00 qps: 478.80 (r/w/o: 335.00/42.60/101.20) lat (ms,95%): 1032.01 err/s: 0.00 reconn/s: 0.00
[ 40s ] thds: 8 tps: 26.60 qps: 531.20 (r/w/o: 371.60/53.20/106.40) lat (ms,95%): 1304.21 err/s: 0.00 reconn/s: 0.00
[ 50s ] thds: 8 tps: 21.30 qps: 427.00 (r/w/o: 298.90/41.70/86.40) lat (ms,95%): 1235.62 err/s: 0.00 reconn/s: 0.00
[ 60s ] thds: 8 tps: 18.50 qps: 368.40 (r/w/o: 257.70/40.90/69.80) lat (ms,95%): 1453.01 err/s: 0.00 reconn/s: 0.00
SQL statistics:
queries performed:
read: 29344
write: 3390
other: 9148
total: 41882
transactions: 2077 (32.16 per sec.)
queries: 41882(648.45 per sec.)
ignored errors: 19 (0.29 per sec.)
reconnects: 0 (0.00 per sec.)
General statistics:
total time: 64.5861s
total number of events: 2077
Latency (ms):
min: 10.06
avg: 235.33
max: 7159.95
95th percentile: 1013.60
sum: 488775.18
Threads fairness:
events (avg/stddev): 259.6250/35.75
execution time (avg/stddev): 61.0969/1.45queries：查询总数及qps
transactions：事务总数及tps
Latency-95th percentile：前95%的请求的最大响应时间，本例中是1013毫秒，这个延迟非常大，是因为我用的MySQL服务器性能很差；在正式环境中这个数值是绝对不能接受的。
清除数据
sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua --oltp-tables-count=3 --oltp-table-size=100000 --mysql-user=root --mysql-host=106.13.177.139 --mysql-password=123.com --mysql-db=test cleanupsysbench的其他特性
内存
测试内存的连续读写性能
线程
测试线程调度器的性能。对于高负载情况下测试线程调度器的行为非常有用。
互斥锁
测试互斥锁的性能，方式是模拟所有线程在同一时刻并发运行，并都短暂请求互斥锁(互斥锁mutex是一种数据结构，用来对某些资源进行排他性访问控制，防止因并发访问导致问题)。
顺序写
测试顺序写的性能。这对于测试系统的实际性能瓶颈很重要。可以用来测试RAID控制器的高速缓存的性能状况。
支持分享
页:
[1]
