sysbench 0.5 性能测试工具使用手册

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
云数据库 RDS PostgreSQL,高可用系列 2核4GB
简介:
1. sysbench 介绍
  sysbench是一个模块化的、跨平台、多线程基准 测试工具,主要用于评估测试各种不同系统参数 下的 数据库负载情况。关于这个项目的详细介绍请看:http://sysbench.sourceforge.net。
  它主要包括以下几种方式的测试:
  cpu性能
  磁盘io性能
  调度程序性能
  内存分配及传输速度
  POSIX线程性能
  数据库性能(OLTP基准测试)
  目前sysbench主要支持 MySQL,Pgsql和 Oracle这3种数据库。
   2. 安装sysbench
  基于Debain的 操作系统,可以直接安装:
  sudo apt-get install sysbench
  也可以下载源码,然后自己编译安装。
  项目主页:http://sysbench.sourceforge.net/
  下载地址:http://sourceforge.net/projects/sysbench
  文档地址:http://sysbench.sourceforge.net/docs
   3. 开始测试
  3.1 CPU性能测试
  根据官网的介绍可知:CPU测试使用64位整数,测试计算素数直到某个最大值所需要的时间。
  sysbench --test=cpu --cpu-max-prime=20000 run
  输出如下:
Maximum prime number checked in CPU  test: 200000
Test execution summary:
total time:                          286.5703s
total number of events:              10000
total time taken by event execution: 285197.4463
per-request statistics:
min:                                109.67ms
avg:                              28519.74ms
max:                              36760.02ms
approx.  95 percentile:           31751.56ms
Threads fairness:
events (avg/stddev):           9.7656/0.81
execution time (avg/stddev):   278.5131/6.05
  我们只需要关心测试的总时间(total time)即可。
  CPU性能测试有一个需要注意的地方,上面的测试只使用了一个线程,如果在两个cpu processor不同的电脑上做比较,这是不公平的。公平的做法是指定合理的线程数,如下所示:
  sysbench --test=cpu --num-threads=`grep "processor" /proc/cpuinfo | wc -l` \
  --cpu-max-prime=200000 run
  补充知识:
  查看CPU核数的方法
  查看物理cpu个数
  grep "physical id" /proc/cpuinfo | sort -u | wc -l
  查看核心数量
  grep "core id" /proc/cpuinfo | sort -u | wc -l
  查看线程数量
  grep "processor" /proc/cpuinfo | sort -u | wc -l
  在sysbench的测试中,--num-threads取值为"线程数量"即可,再大的值没有什么意义,对测试结果也没有什么影响。
   3.2 线程(thread)测试
  测试线程调度器的性能。对于高负载情况下测试线程调度器的行为非常有用。
  sysbench --test=threads --num-threads=64 run
  下面是输出结果:
Number of threads: 64
Doing thread subsystem performance test
Thread yields per test: 1000 Locks used: 8
Threads started!
Done.
Test execution summary:
total time: 4.5845s
total number of events: 10000
total time taken by event execution: 291.9995
per-request statistics:
min: 0.76ms
avg: 29.20ms
max: 152.71ms
approx. 95 percentile: 71.11ms
Threads fairness:
events (avg/stddev): 156.2500/5.81
execution time (avg/stddev): 4.5625/0.02
  说实话,我也不怎么会分析这个测试结果,网上搜了半天也没有搜到,几乎所有的资料都是简单的罗列出测试结果, 也不告诉我们应该怎么分析,实在是太不照顾新手了。 我自己是通过(total time:)判断线程调度的性能的,下面是我在服务器上运行这个测试的输出:
Number of threads: 64
Doing thread subsystem performance test
Thread yields per test: 1000 Locks used: 8
Threads started!
Done.
Test execution summary:
total time: 2.4829s
total number of events: 10000
total time taken by event execution: 157.3468
per-request statistics:
min: 0.21ms
avg: 15.73ms
max: 166.69ms
approx. 95 percentile: 119.14ms
Threads fairness:
events (avg/stddev): 156.2500/22.25
execution time (avg/stddev): 2.4585/0.02
  可以看到total time 比在我自己电脑上少了一半,服务器的线程调度肯定比普通电脑快多了。

 3.3 互斥锁(mutex)
  测试互斥锁的性能,方式是模拟所有线程在同一时刻并发运行,并都短暂请求互斥锁。
sysbench --test=mutex --num-threads=16 --mutex-num=2048 \
--mutex-locks=1000000 --mutex-loops=5000 run
输出结果如下:

Number of threads: 16
Doing mutex performance test
Threads started!
Done.
Test execution summary:
total time: 3.6123s
total number of events: 16
total time taken by event execution: 57.6636
per-request statistics:
min: 3580.79ms
avg: 3603.98ms
max: 3610.94ms
approx. 95 percentile: 10000000.00ms
Threads fairness:
events (avg/stddev): 1.0000/0.00
execution time (avg/stddev): 3.6040/0.01
  为了不误导别人,我就不解释各参数的含义了,可以请参考这里。
   3.4 内存测试
  内存测试测试了内存的连续读写性能。
  sysbench --test=memory --memory-block-size=8K --memory-total-size=2G  --num-threads=16 run
  上面这条语句指定了整个测试过程中,传输2G的数据量,每个block的大小为8K(大写的K)。 测试结果如下所示,我们最关心的是吞吐量(8030.45MB/sec),和后面的磁盘io 测试结果比较可知,内存的连续读写比磁盘的连续读写快十几倍。
Number of threads: 16
Doing memory operations speed test
Memory block size: 8K
Memory transfer size: 2048M
Memory operations type: write
Memory scope type: global
Threads started!
Done.
Operations performed: 262144 (1027897.89 ops/sec)
2048.00 MB transferred (8030.45 MB/sec)
Test execution summary:
total time: 0.2550s
total number of events: 262144
total time taken by event execution: 3.1911
per-request statistics:
min: 0.00ms
avg: 0.01ms
max: 29.55ms
approx. 95 percentile: 0.00ms
Threads fairness:
events (avg/stddev): 16384.0000/926.14
execution time (avg/stddev): 0.1994/0.02
   3.5 文件IO基准测试
  文件IO(fileio)基准测试可以测试系统在不同IO负载下的性能。这对于比较不同的硬盘驱动器,不同的RAID 卡,不同的RAID 模式,都很有帮助。可以根据测试结果调整IO子系统。文件IO基准测试模拟了很多InnoDB 的IO特性。
  测试的第一步是准备(Prepare)阶段,生成测试用到的数据文件,生成的数据文件至少要比内存大。 如果文件中的数据能完全放入内存中,则操作系统 缓存大部分的数据,导致测试结果无法体现IO密集型的工作负载。首先通过下面的命令创建一个数据集:
  sysbench --test=fileio --file-total-size=40G prepare
  这个命令会在当前工作目录下创建测试文件,后续的运行(run)阶段将通过读写这些文件进行测试。 第二步就是运行(run)阶段,针对不同的IO 类型有不同的测试选项:
  seqwr 顺序写入
  seqrewr 顺序重写
  seqrd 顺序读取
  rndrd 随机读取
  rndwr 随机写入
  rndrw 混合随机读/写
  下面的命令运行文件I/O混合随机读/写基准测试:
  sysbench --test=fileio --file-total-size=40G --file-test-mode=rndrw\
  --init-rng=on --max-time=300 --max-requests=0 run

  simple 与 --oltp-read-only 的区别
  simple模式和在complex模式下开启read-only选项都只包含select语句。但是 simple 模式只包含最简单的select语句,相反地,complex 模式中,如果我们开启read-only 选项,即--oltp-read-only=on,则会包含复杂的SQL语句。如:
  SELECT SUM(K) FROM sbtest WHERE id BETWEEN N and M
  SELECT DISTINCT c FROM sbtest WHERE id BETWEEN N and M ORDER BY c
   测试自有的存储引擎
  测试自有的存储引擎需要告诉sysbench,这个存储引擎是否支持事务。
  如下所示:
  准备
  sysbench --test=oltp --mysql-table-engine=tnt --mysql-engine-trx=yes \
  --oltp-table-size=100000 --mysql-user=root --mysql-db=test \
  --mysql-socket=/data/ntse/lmx/sysbench/var/mysqld.sock \
  prepare
  测试
  sysbench --test=oltp --mysql-table-engine=tnt --mysql-engine-trx=yes \
  --oltp-table-size=100000 --mysql-user=root --mysql-db=test \
  --mysql-socket=/data/ntse/lmx/sysbench/var/mysqld.sock \
  --oltp-test-mode=complex --num-threads=16 --max-time=720 \
  --max-requests=0 run
  清除
  sysbench --test=oltp --mysql-table-engine=tnt --mysql-engine-trx=yes \
  --oltp-table-size=100000 --mysql-user=root --mysql-db=test \
  --mysql-socket=/data/ntse/lmx/sysbench/var/mysqld.sock \
  clean
   4. sysbench 0.5
  4.1 下载安装
  下载
  bzr branch lp:sysbench
  安装依赖库
  sudo apt-get installlibtool
  安装
  tar -zxvf sysbench.tar.gz
  cd sysbench
  ./autogen.sh
  ./configure
  make
  #make install #可选
  开始测试
cd sysbench/sysbench
./sysbench --test=./tests/db/oltp.lua
--debug=yes \
--mysql-host=localhost \
--mysql-socket=PATH/mysqld.sock \
--mysql-db=test \
--mysql-table-engine=innodb \
--mysql-engine-trx=yes \
--mysql-user=root \
--max-requests=0 \
--max-time=60 \
--num-threads=16 \
--oltp-table-size=100000 \
--report-interval=10 [prepare|run|cleanup]
  解释
  --debug 参数用以打印更加详细的调试信息
  --report-interval 用以打印中间结果
  除了测试oltp,sysbench 0.5还可以进行插入操作的性能测试(insert.lua),选择操作的性能测试(select.lua)等。   


最新内容请见作者的GitHub页:http://qaseven.github.io/
   
目录
相关文章
|
2月前
|
机器学习/深度学习 人工智能 测试技术
EdgeMark:嵌入式人工智能工具的自动化与基准测试系统——论文阅读
EdgeMark是一个面向嵌入式AI的自动化部署与基准测试系统,支持TensorFlow Lite Micro、Edge Impulse等主流工具,通过模块化架构实现模型生成、优化、转换与部署全流程自动化,并提供跨平台性能对比,助力开发者在资源受限设备上高效选择与部署AI模型。
315 9
EdgeMark:嵌入式人工智能工具的自动化与基准测试系统——论文阅读
|
2月前
|
Java 测试技术 API
自动化测试工具集成及实践
自动化测试用例的覆盖度及关键点最佳实践、自动化测试工具、集成方法、自动化脚本编写等(兼容多语言(Java、Python、Go、C++、C#等)、多框架(Spring、React、Vue等))
135 6
|
3月前
|
前端开发 Java jenkins
Jmeter压力测试工具全面教程和使用技巧。
JMeter是一个能够模拟高并发请求以检查应用程序各方面性能的工具,包括但不限于前端页面、后端服务及数据库系统。熟练使用JMeter不仅能够帮助发现性能瓶颈,还能在软件开发早期就预测系统在面对真实用户压力时的表现,确保软件质量和用户体验。在上述介绍的基础上,建议读者结合官方文档和社区最佳实践,持续深入学习和应用。
828 10
|
3月前
|
监控 Java 数据挖掘
利用Jmeter工具进行HTTP接口的性能测试操作
基础上述步骤反复迭代调整直至满足预期目标达成满意水平结束本轮压力评估周期进入常态监控阶段持续关注系统运转状态及时发现处理新出现问题保障服务稳定高效运作
501 0
|
4月前
|
敏捷开发 运维 数据可视化
DevOps看板工具中的协作功能:如何打破开发、测试与运维之间的沟通壁垒
在DevOps实践中,看板工具通过可视化任务管理和自动化流程,提升开发与运维团队的协作效率。它支持敏捷开发、持续交付,助力团队高效应对需求变化,实现跨职能协作与流程优化。
|
5月前
|
Java 测试技术 容器
Jmeter工具使用:HTTP接口性能测试实战
希望这篇文章能够帮助你初步理解如何使用JMeter进行HTTP接口性能测试,有兴趣的话,你可以研究更多关于JMeter的内容。记住,只有理解并掌握了这些工具,你才能充分利用它们发挥其应有的价值。+
955 23
|
5月前
|
数据可视化 测试技术 Go
Go 语言测试与调试:`go test` 工具用法
`go test` 是 Go 语言内置的测试工具,支持单元测试、基准测试、示例测试等功能。本文详解其常用参数、调试技巧及性能测试命令,并提供实际项目中的应用示例与最佳实践。
|
4月前
|
人工智能 数据可视化 测试技术
UAT测试排程工具深度解析:让验收测试不再失控,项目稳稳上线
在系统交付节奏加快的背景下,“测试节奏混乱”已成为项目延期的主因之一。UAT测试排程工具应运而生,帮助团队结构化拆解任务、清晰分配责任、实时掌控进度,打通需求、测试、开发三方协作闭环,提升测试效率与质量。本文还盘点了2025年热门UAT工具,助力团队选型落地,告别靠表格和群聊推进测试的低效方式,实现有节奏、有章法的测试管理。
|
5月前
|
弹性计算 JavaScript Ubuntu
WebSocket协议相关的测试命令工具使用简介
本文介绍了针对WebSocket的测试工具wscat和websocat的基本使用方法,以及通过curl命令测试HTTP/HTTPS协议的方式。对于WebSocket,直接使用curl测试较为复杂,推荐使用wscat或websocat。文中详细说明了这两种工具的安装步骤、常用参数及连接示例,例如在ECS上开启8080端口监听并进行消息收发测试。此外,还提供了curl命令的手动设置头部信息以模拟WebSocket握手的示例,但指出curl仅能作为客户端测试工具,无法模拟服务器。
1195 4
|
监控 网络协议 Java
一些适合性能测试脚本编写和维护的工具
一些适合性能测试脚本编写和维护的工具
473 59