暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

MySQL 压测

Ty 2022-05-12
909

1.介绍

1.1 测试分类

  • 基准测试

  • 并发测试

  • 负载测试

  • 压力测试

  • 稳定性测试


1.2 基准测试介绍

  • 基准测试(benchmark)

基准测试是针对系统设计的一种压力测试,为系统建立一个性能基准,以后当系统的环境参数发生变化后,在进行一次相同标准下的测试,可以看出变化对性能的影响,可以再较好的阶段发现性能问题。

基准测试可以理解为压力测试的一种。但基准测试不关心业务逻辑,更加简单、直接,数据可以由工具生成,不要求真实;而压力测试一般考虑业务逻辑(如购物车业务),要求真实数据。


  • 基准测试目标

    评估当前系统

    寻找存在瓶颈

    预测未来性能


对于多数 Web 应用,整个系统的瓶颈在于数据库;原因很简单: Web 应用中的其他因素,例如网络带宽、负载均衡节点、应用服务器(包括 CPU、内存、硬盘灯、连接数等)、缓存,都很容易通过水平的扩展(俗称加机器)来实现性能的提高。

而对于 MySQL ,由于数据一致性的要求,无法通过增加机器来分散向数据库写数据带来的压力;虽然可以通过前置缓存( Redis 等)、读写分离、分库分表来减轻压力,但是与系统其它组件的水平扩展相比,受到了太多的限制。

而对数据库的基准测试的作用,就是分析在当前的配置下(包括硬件配置、 05 、数据库设置等)数据库的性能表现,从而找出 MySQL 的性能阈值,并根据实际系统的要求调整配置。


1.2.1 基准测试的方式

  • 针对整个系统的整体测试,即集成式( full-stack)基础测试.通过 http 请求进行测试,如通过浏览器、 App 或 postman 等测试工具.该方案的优点:能够更好的针对整个系统,测试结果更加准确;缺点:是设计复杂实现困难。

  • 单独测试 MySQL ,即单组件式( single 一 component )基准测试。只针对 MySQL 的基准测试:优点和缺点与针对整个系统的测试恰好相反。


1.2.2 基准测试的指标

  • 系统吞吐量

    一个系统的吞度量(承压能力)与 request 对 CPU 的消耗、外部接口、 IO 等等紧密关联。

    单个 request 对 CPU 消耗越高,外部系统接口、 IO 影响速度越慢,系统吞吐能力越低,反之越高。

系统吞吐里几个重要参数: QPS、 TPS 、并发数、响应时间。


TPS / QPS :衡量吞吐量。

响应时间:包括平均响应时间、最小响应时间、最大响应时间、时间百分比等,其中时间百分比参考意义较大,如前 95 %的请求的最大响应时间。

并发量:同时处理的查询请求的数量。


  • 并发数

系统同时处理的请求、事务数。

所有用户在同一时刻做同一操作,主要是为了验证榴字或数据库对并发处理的能力。

多个用户对系统发起了多个请求,这些请求可以是同一种操作,也可以是不同的操作,混合测试。

  • 响应时间

响应时间反应完成某个业务所需的时间,一般取平均响应时间。

响应时间=网络传输时间(请求)+服务器处理时间+网络传输时间(响应时间)+页面前端解析渲染时间

  • 每秒通过事务数(TPS)

    每秒通过的事务数(吞吐量),是直接反映系统性能的指标,此值比较大,说明系统性能比较好,用户每分钟执行 6 个事务, TPS 为 6 / 60s = 0.10 TPS 。同时我们会知道事务的响应时间, 60 秒完成 6 个事务也同时代表每个事务的响应时间为 10 秒。

  • 每秒查询事务数(QPS)

    单个进程每秒请求服务器的成功次数。

    每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准,此值比较大,说明系统性能比较好。

QPS 基本类似于 TPS ,但是不同的是,对于一个页面的一次访问,形成一个 TPS ;但一次页面请求,可能产生多次对服务器的请求,服务器对这些请求,就可计入 QPS 之中。

  • 事务

    用户一个或一系列的操作,代表一定的功能,在程序上的实现就是一段代码区块,所有性能测试其实最终都是围绕着事务开始的,事务代表用户的使用方法和结果不同的操作组合成不同的事务,不同的事务又能组合成不同的场景。

  • 事务请求时间

    从这人事务发起到最终处理完毕的所有时间。

  • 每秒点击数

代表用户每秒向外部服务器提交的 HTTP 请求。

TPS(吞吐量)计算公式:

所以利特尔法则在负载模型中解释为:

系统内平均用户数 = 平均响应时间 * 吞吐量( TPS = 用户数 / 平均响应时间)

N = ( R + Z ) * X

N ,用户数

R ,平均响应时间(也可能是速率)

Z ,思考时间

X ,吞吐量(如 TPS )

如: N (用户数)= 1000 , R(平均响应时间) = 5 , Z(思考时间) = 0 ,则 X (吞吐量) = 1000 / 5 = 500 TPS


TPS 目标值确定--二八原则:在性能测试中通常使用二八原则来量化业务需求。

二八原则:指 80 %的业务量在 20 %的时间里完成。

计算例子 1 :如某个公司 1000 个员工,在周五下午 15 点 -- 17 点有 90%的员工登陆公司周报系统

则:业务量 = 1000 个,时间 = 2 x 60 x 60 = 7200 秒

根据二八原则来计算 15 点到 17 点的 TPS = ( 90% *业务量* 80% ) / ( 20% * 时间) = 0.9 * 1000 * 0.8 / ( 0.2 * 7200 ) = 0.5个/s

注:二八原则计算的结果并非在线并发用户数,是系统要达到的处理能力(吞吐量)


计算例子 2 :一个高速路有 10 个入口 ,每个入口每秒钟只能进 1 辆车

1 、请问 1 秒钟最多能进几辆车?

TPS = 10

2 、每辆车需要多长时间进行响应?

响应时间 reponse time = 1

3 、改成 20 辆车,每秒能进几辆?每辆车的响应时间是多长?

TPS = 10 , reponse time = 1 ( 10 个为一等份,分成两等份)

平均 tps ( 10 / 1 + 10 / 2 ) / 2 = 7.5 平均相应时间 ( 2 + 1 ) / 2 = 1.5

4 、入口扩展到 20 个,每秒能进几辆?每辆车的响应时间是多长?

TPS = 20 , reponse time = 1


计算例子 3 :

以目前生产核心系统交易量峰 800万笔/天为基数,每年 20% 的业务增长,上收业务占比柜面业务的 40%

计算前端系统 5 年后业务量为:

800 万* ( 1 + 20 % ) " ( 1 + 20 % ) " ( 1 + 20 % ) " ( 1 + 20 % ) " ( l + 20 % ) " 30 % * 40 % = 238 . 8 万笔/天。

以系统未来预期日交易量 238.8 万笔 / 天为测试目标,用常规性能测试 TPS 估算方法计算,峰值交易丁 TPS 为 80%的交易量在 20%的时间内产生,以系统交易时间 12 小时计算。

测试目标 TPS 为: ( 238.8 万 * O , 8 ) / ( 12 * 0.2 * 3600 秒) = 221 笔 / 秒。


  • 计算 QPS 与并发数

QPS 统计方式(一般使用压力测试工具进行统计)

QPS = 总请求数 / (进程总数 * 请求时间)

并发数 = QPS * 平均相应时间


  • 通过 QPS 计算 PV

    单台服务器每天 PV 计算

    公式 1 :每天总 PV = QPS * 3600 * 6 (6 个小时高峰期)

    公式 2 :每天总 PV = QPS * 3600 * 8 (8 个小时高峰期)

    服务器数量计算方式 1 = 每天总 PV / 单台服务器每天总 PV


计算案例 5 :

公司有一个 OA 办公系统,早上 8 :30 上班, 8 : 00 -- 8 : 30 的 30 分钟的时间里用户会登录打卡。

公司员工为 5000 人,平均每个员上登录打卡系统的时长为 5 分钟。

可以用下面的方法计算:

QPS = 总请求数/(进程总数 * 请求时间)

QPS ( TPS ) = 5000 / ( 1 * ( 30 * 60 ) ) = 2.8 事务 / 秒

平均响应时间为二 5 * 60 秒= 300 秒/人

并发数= QPS *平均响应时间= 5000 / ( 1 " ( 30 " 60 ) ) " ( 5 * 60 ) = 840


  • PV 访问量

即页面访问量,每打开一次页面 PV 计数+ 1 ,刷新页面也是,在一定统计周期内用户每打开或刷新一个页面就记录 1 次,多次打开或刷新同一页面则浏览量累计。


  • UV 访问数

指独立访客访问数,一台电脑终端为一个访客。


  • IP 访问数量(IV)

指独立 IP 访问数,计算是以一个独立的 IP 在一个计算时段内访问网站计算为 1 次 IP 访问数

在同一个计算时段内不管这个 IP 访问多少次均计算为 1 次。

计算时段有以 1 天为一个计算时段,也有以 1 个小时为一个计算时段。


计算案例 6:一个系统需要多少服务器?

计算原理:每天 80% 的访问集中在 20%时间里,这 20% 时间叫做峰值时间。

计算公式:(总 PV 数 * 80%)/(每天秒数 * 20%)= 峰值时间每秒请求数(QPS)

所需机器:峰值时间每秒 QPS/单台机器的 QPS = 需要的机器


问:每天 5000w PV 的在单台机器上,这台机器需要多少 QPS?

答: ( 50000000 * 0.8 ) / ( 86400 * 0.2 ) = 2315 ( QPS )


问:如果一台机器的 QPS 是 100 ,需要多少台机器来支持?

答: 2315 / 100 = 24


基准测试的指标库里如何查看 QPS 与 TPS :

  • QPS (每秒 query 里)

QPS = Questions ( or Queries ) / seconds

mysql > show global status Iike ' Question % " ;


  • TPS(每秒事务量)

TPS = ( Com _ commit + Com _ rollback ) / seconds

mysql > show global status like ' Com _ commit ' ;

mysql > show global status like " Com _ rollback ' ;


1.3 压力测试介绍

压力测试就是对系统不断加压,看系统什么时候崩溃,用这个来确定系统的瓶颈,以获取系统的最佳并发数。

  • 采购新设备,通过压力测试来评估新设备的性能。

  • 新业务上线,测试功能和数据库并发。

  • 数据库版本升级测试,评估性能提升。


1.4 测试过程中关注指标及设备选型

  • 硬件选型(物理服务器)

  • CPU 性能( top )

  • CPU 配置(多少核、超线程、频率)

  • 内存使用比例( top , vmstat , free -m )

  • 内存配置(内存大小、大页)

  • IO 使用情况( iostat , vmstat , IOPS 一即每秒进行读写( I / O)操作的次数。)

  • 磁盘配置( 10 读写策略、 RAID 方式、存储级别、 550 、 SAS 、 STAT )

  • 操作系统(内存参数、版本 BUG 、文件系统)

  • 数据库( Q PS , TPS ,响应时间,慢查询, InnoDB 信息,日志配置,参数合理度)

  • 网络(网卡、交换机、流量限制)


1.5 测试过程中关澎数据库指标

  • 高吞吐量

满足高并发下的大数据量交互需求,满足数据备份或 ETL 过程的大数据量迁移。

  • 负载均衡

足高并发下数据库的负载均衡能力,需求分析需要收集数据库的部署架构、负载均衡策略等数据信息。

  • 读写分离

获取需求的要点是明确哪些是写节点,哪些是读节点,并且切换的策略什么,数据同步的策略是什么。


1.6 测试过程中关注数据库指标.

  • 分区分片(分库分表)

明确需要对哪些数据块进行切分,分别分散到哪几台数据库主机上;需要对哪些大表进行数据水平切分,并且分布到哪些 DB 或 table 中。通过需求分析,做出数据切分的合理性判断,以及做出系统可测性的判断。

  • 高并发

根据数据库应用需求,进一步制定数据库的高并发需求,估算出单台数据库的 API 接口压力和需要满足的并发能力。

  • 高可用性

高可用性可能也综合涉及到数据的多项能力,主要应用的是集群技术,HA 容错及互备技术,体现的是无故障运行.获取需求的要点是明确高可用性技术架构,了解 HA 采用的工作方式,以及掌握故障切换方法和数据一致性验证需求。


1.7 测试过程前需要收集哪些信息

  • 需求信息收集 - 任务 / 交易分布

收集有哪些主要交易任务

在一天内的某些特定时刻系统都有哪些主要操作,以及操作量(时间段、交易量、事务数)


  • 需求信息收集 -- 交易混合操作

比如:

高峰期又有哪些操作?

某个小时,做 A 业务多少,做 B 业务多少,高峰期多少,正常业务多少?

中间件操作有多少?数据库操作有多少?

如果任务失败,那么风险有多少?


2. MySQL 测试工具

  • sysbench

    sysbench 是一个压力测试工具、可以用它来测试 CPU、mem、disk、thread、mysql、postgr、oracle;用它来测试 mysql 非常不错!

  • mysqlslap

mysqlslap 是 MySQL 5.1.4 之后自带的 benchmark 基准测试工具,该工具可以模拟多个客户端同时并发的向服务器发出查询更新,给出了性能测试数据而且提供了多种引擎的性能比较。

  • 其他工具

Tpcc-MySQL(OLTP)、tpch(OLAP)、MySQL super-smack、MyBench、LoadRunner


3. OLTP 与 OLAP

OLTP:联机事务处理OLTP(on-line transaction processing)主要是执行基本日常的事务处理,比如数据库记录的增删查改。比如在银行的一笔交易记录,就是一个典型的事务。

OLTP 的特点一般有:

1.实时性要求高。早期银行异地汇款,要隔天才能到账,而现在是分分钟到账的节奏,说明现在银行的实时处理能力大大增强。

2.数据量不是很大,生产库上的数据量一般不会太大,而且会及时做相应的数据处理与转移。

3.交易一般是确定的,比如银行存取的金额肯定是确定的,所以 OLTP 是对确定性的数据进行存取。

4.高并发,并且要求满足 ACID 原则。比如两人同时操作一个银行卡账户,比如大型的购物网站秒杀活动时上万的 QPS 请求。

互联网应用绝大部分属于 OLTP,OLTP 看中服务器 CPU,内存,写事务较多,内存不够则依赖磁盘 IO。


4. sysbench 介绍

sysbench 是一个模块化的、跨平台、多线程基准测试工具,主要用于评估测试各种不同系统参数下的数据库负载情况。

4.1 下载地址

https://github.com/akopytov/sysbench/releases
sysbench-0.5.tar.gz


4.2 支持的测试种类

sysbench 目前可以进行如下几个方面的性能测试:

  • fileio - file I/O test # 磁盘 IO 性能

  • cpu - CPU performance test #CPU 性能

  • memory - Memory functions speed test #内存性能

  • threads - Threads subsystem performance test # POSIX 线程性能

  • mutex - Mutex performance test # 调度程序性能

  • oltp - OLTP test # 数据库性能(OLTP 基准测试)


4.3 sysbench 的缺点

模拟的表结构太简单,不像 tpcc-mysql 那样完整的事务系统,但对于 MySQL 性能压测对比还是很有用的。


5. sysbench 安装

下载地址:https://github.com/akopytov/sysbench/releases


5.1 安装依赖包

# yum install -y make automake libtool pkgconfig libaio-devel libtool unzip


5.2 解压

# unzip sysbench-0.5.zip
# tar zxvf sysbench-0.5.tar.gz


5.3 执行 autogen.sh

# ./autogen.sh


5.4 配置 sysbench

# ./configure --prefix=/data/sysbench --with-mysql=/usr/local/mysql --with-mysql-includes=/usr/local/mysql/include/


5.5 make

# make -j
# make install


5.6 配置环境变量

vi .bash_prifile
PAHT=/data/sysbench/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/mysql/lib


5.7 检查

# sysbench --version


6. sysbench 命令与参数

# sysbench --help
# sysbench [options] …… [testname] [command]
# 常用的 command 有
1) prepare 准备测试,生成数据
2) run 执行测试
3) cleanup 清理数据
4) help
5) version


7. 测试脚本

# 测试脚本在 ./configure 的时候 prefix 参数指定的地址
-rw-r--r-- 1 root root 1001 May 11 13:26 bulk_insert.lua
-rw-r--r-- 1 root root 4133 May 11 13:26 common.lua
-rw-r--r-- 1 root root 384 May 11 13:26 delete.lua
-rw-r--r-- 1 root root 1198 May 11 13:26 insert.lua
-rw-r--r-- 1 root root 3287 May 11 13:26 oltp.lua
-rw-r--r-- 1 root root 386 May 11 13:26 oltp_simple.lua
-rw-r--r-- 1 root root 545 May 11 13:26 parallel_prepare.lua
-rw-r--r-- 1 root root 387 May 11 13:26 select.lua
-rw-r--r-- 1 root root 3996 May 11 13:26 select_random_points.lua
-rw-r--r-- 1 root root 4098 May 11 13:26 select_random_ranges.lua
drwxr-xr-x 3 root root 4096 May 11 13:26 tests
-rw-r--r-- 1 root root 387 May 11 13:26 update_index.lua
-rw-r--r-- 1 root root 596 May 11 13:26 update_non_index.lua


8. sysbench 注意事项及建议

注意事项

  • 尽最不要在 MySQL 服务器运行的机器上进行测试,一方面可能无法体现网络(嘛怕是局域网)的影响,另一方面, sysbench 的运行(尤其是设置的并发数较高时)会影响脚 SQL 服务器的表现

  • 可以逐步增加客户端的并发连接数(-- thread 参教),观察在连接数不同情况下,MySQL 服务器的表现;如分别设置为 10 , 20 , 50 , 100 等。

  • 一般执行模式选择 complex 即可,如果需要特别侧试服务器只读性能,或不使用事务时的性能,可以选择 simple 模式或 nontrx 模式。

complex :侧试最全面,会侧试增删改查,会使用事务。

simple :只侧试简单的查询

nontrx :不仅测试杳询,还测试插入更新等,但不使用事务 。

  • 如果连续进行多次测试,注意确保之前侧试的数据己经被消理千净。

  • 测试表的数量不宜太少,至少要求 20 个表以上;每个表的数据量不宜太少,通常至少要求 1 干万以上,也要根据 DB 服务器的配置适当调整;每轮测试完毕后,中间至少暂停 5 分钟,或者确认系统负权完全恢复空旅状态为止。


建议

  • 在开始测试之前,应该首先明确:应采用针对整个系统的基准测试,还是针对 MySQL 的基准测试,还是二者都需要。

  • 如果需要针对 MySQL 的基准测试,那么还需要明确精度方面的要求:

    是否需要使用生产环境的真实数据,还是使用工具生成也可以;

    前者实施起来更加繁琐。如果要使用真实数据,尽量使用全部数据,而不是部分数据。

  • 基准测试要进行多次才有意义。

  • 测试时需要注意主从同步的状态。

  • 测试必须模拟多线程的情况,但线程情况不但无法模拟真实的效率,也无法模拟阻塞甚至死锁情况。


9. sysbench 测试

9.1 Sysbench OLTP 测试 -- 混合读写

9.1.1 常用参数

——oltp-test-mode=STRING         # 使用{simple,complex,nontrx,sp} [complex]的测试类型
——oltp-reconnect-mode=STRING    # 重新连接模式{session,transaction,query,random} [session]
——oltp-sp-name=STRING           # 存储过程的名称。默认为空
——oltp-read-only=[on|off]       # 只读模式。Update,delete,insert语句不可执行。默认是off
——oltp-skip-trx=[on|off]        # 省略begin/commit语句。默认是off
——oltp-range-size=N             # 范围查询的范围大小[100]
——oltp-point-selects=N          # N个点选中次数[10]
——oltp-simple-ranges=N          # N个简单范围[1]
——oltp-sum-ranges=N             # N求和范围的N个数目
——oltp-order-ranges=N           # N个有序的范围[1]
——oltp-distinct-ranges=N        # N个不同的范围[1]
——oltp-index-updates=N          # N索引更新次数[1]
——oltp-non-index-updates=N      # N个非索引更新次数
——oltp-nontrx-mode=STRING       # 非事务性测试的模式{select, update_key, update_nokey, insert, delete} [select]
——oltp-auto-inc=[on|off]        # 是否应该在id列上使用AUTO_INCREMENT(或等效的)
——oltp-connect-delay=N          # 连接到数据库后的睡眠时间(以微秒计)[10000]
——oltp-user-delay-min=          # 每个请求后休眠的最小时间(以微秒为单位)
——oltp-user-delay-max=          # 每个请求后休眠的最大时间(以微秒为单位)
——oltp-table-name=STRING        # 测试表名
——oltp-table-size=              # 测试表中的记录数[10000]
——oltp-dist-type=STRING         # #分布的随机数{[uniform(均匀分布),Gaussian(高斯分布),special(空间分布)}。默认是special
——oltp-dist-iter=N              # N次迭代用于生成数字[12]
——oltp-dist-pct=                # 百分之多少的数据视为热点数据
——oltp-dist-res=                # 热点数据的访问频率



9.1.2 数据准备

mysql> create database sbtest;
cd /data/sysbench/share/sysbench   # configure 时 --prefix 参数指定的路径 /data/sysbench

# sysbench --test=./oltp.lua --mysql-host=192.168.10.22 --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=10 --oltp-table-size=10000 --threads=10 --max-time=120 --report-interval=10 prepare


9.1.3 执行测试

# sysbench --test=./oltp.lua --mysql-host=192.168.10.22 --mysql-port=3306 --mysql-user=root --mysql-password=123 --oltp-test-mode=complex --oltp-tables-count=10 --oltp-table-size=10000 --threads=10 --max-time=120 --report-interval=10 run >> /data/sysbench_test.log


9.1.4 清理数据

# sysbench --test=./oltp.lua --mysql-host=192.168.10.22 --mysql-port=3306 --mysql-user=root --mysql-password=123 cleanup


9.1.5 测试结果

# cat /data/sysbench_test.log 
sysbench 0.5: multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1
Report intermediate results every 10 second(s)
Random number generator seed is 0 and will be ignored

Initializing worker threads...

Threads started!

[ 10s] threads: 1, tps: 113.42, reads: 1589.21, writes: 454.06, response time: 13.28ms (95%), errors: 0.00, reconnects: 0.00
[ 20s] threads: 1, tps: 128.89, reads: 1804.48, writes: 515.57, response time: 10.73ms (95%), errors: 0.00, reconnects: 0.00
[ 30s] threads: 1, tps: 127.26, reads: 1781.68, writes: 509.05, response time: 11.71ms (95%), errors: 0.00, reconnects: 0.00
[ 40s] threads: 1, tps: 94.30, reads: 1320.20, writes: 377.20, response time: 14.22ms (95%), errors: 0.00, reconnects: 0.00
[ 50s] threads: 1, tps: 126.83, reads: 1774.37, writes: 506.94, response time: 11.68ms (95%), errors: 0.00, reconnects: 0.00
[ 60s] threads: 1, tps: 127.99, reads: 1792.99, writes: 511.94, response time: 10.55ms (95%), errors: 0.00, reconnects: 0.00
[ 70s] threads: 1, tps: 131.32, reads: 1838.57, writes: 525.68, response time: 10.68ms (95%), errors: 0.00, reconnects: 0.00
[ 80s] threads: 1, tps: 137.20, reads: 1920.73, writes: 548.58, response time: 9.84ms (95%), errors: 0.00, reconnects: 0.00
OLTP test statistics:
queries performed:
read: 140000 -- 读总数
write: 40000 -- 写总数
other: 20000 -- 其他操作总数(SELECT、INSERT、UPDATE、DELETE之外的操作,例如COMMIT等)
total: 200000 -- 全部总数
transactions: 10000 (123.67 per sec.) -- 总事务数(每秒事务数)
read/write requests: 180000 (2226.03 per sec.) -- 读写总数(每秒读写次数)
other operations: 20000 (247.34 per sec.) -- 其他操作总数(每秒其他操作次数)
ignored errors: 0 (0.00 per sec.) -- 忽略的错误数
reconnects: 0 (0.00 per sec.) -- 重新连接次数

General statistics: -- 一般统计结果
total time: 80.8615s -- 总耗时
total number of events: 10000 -- 共发生多少事务数
total time taken by event execution: 80.8360s -- 所有事务耗时相加(不考虑并行因素)
response time: -- 响应时间
min: 6.03ms -- 最小耗时
avg: 8.08ms -- 平均耗时
max: 85.77ms -- 最长耗时
approx. 95 percentile: 13.18ms -- 超过99%平均耗时

Threads fairness: -- 与线程相关的指标
events (avg/stddev): 10000.0000/0.00 -- 事件(平均值/偏差)
execution time (avg/stddev): 80.8360/0.00 -- 执行时间(平均值/偏差)


9.2 sysbench 只读测试

9.2.1 数据准备

# sysbench --test=./oltp.lua --mysql-host=192.168.10.22 --mysql-port=3306 --mysql-user=root --mysql-password=123 --mysql-db=sbtest --oltp-test-mode=nontrx --oltp-tables-count=10 --oltp-table-size=10000 --threads=10 --max-time=120 --report-interval=10 --rand-init=on --max-requests=0 --oltp-nontrx-mode=select --oltp-read-only=on --oltp-skip-trx=on prepare


9.3 文件 IO 测试

9.3.1 常用参数

[root@tydb010 sysbench]# sysbench --test=fileio help
sysbench 0.5: multi-threaded system evaluation benchmark

fileio options:
--file-num=N # 创建测试文件的数量,默认 128
--file-block-size=N # 测试时文件块的大小。默认 16384(16K)
--file-total-size=SIZE # 测试文件总体大小。默认 2G
--file-test-mode=STRING # 测试模式,rndrd 表示随机读取
--file-io-mode=STRING # 文件操作模式,sync同步,async异步,fastmmap快速map映射,slowmmap慢map映射。默认sync
--file-async-backlog=N #
--file-extra-flags=STRING # 使用额外的标志来打开文件,sync,dsync,direct,默认为空
--file-fsync-freq=N # 执行 fsync() 的频率,0 - 不适用 fsync。默认 100
--file-fsync-all=[on|off] # 每执行完一次写操作就执行一次 fsync。默认 off
--file-fsync-end=[on|off] # 在测试结束时才执行 fsync。默认 on
--file-fsync-mode=STRING # 使用哪种方法进行同步 fsync,fdatasync。默认 fsync
--file-merged-requests=N # 如果可以,合并最多的 IO 请求数( 0 - 表示不合并)。默认 0
--file-rw-ratio=N # 测试时的读写比例。默认 1.5


9.3.2 文件测试模式

seqwr   # 顺序写
seqrew # r 顺序读写
seqrd # 顺序读
rndrd # 随机读
rndwr # 随机写
rndrw # 随机读写


9.3.2 数据准备

# sysbench --test=fileio --num-threads=4 --file-total-size=20M --file-test-mode=rndrw prepare


9.3.3 测试

# sysbench --test=fileio --num-threads=4 --file-total-size=1G --file-test-mode=rndrw run
sysbench 0.5: multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 4
Random number generator seed is 0 and will be ignored


Extra file open flags: 0
128 files, 8Mb each
1Gb total file size
Block size 16Kb
Number of IO requests: 10000
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads...

FATAL: Failed to read file! file: 13 pos: 5505024 errno = 0 (Success)
Threads started!

FATAL: Failed to read file! file: 48 pos: 1835008 errno = 0 (Success)
FATAL: Failed to read file! file: 96 pos: 2834432 errno = 0 (Success)
FATAL: Failed to read file! file: 26 pos: 3178496 errno = 0 (Success)
Operations performed: 1 reads, 1 writes, 0 Other = 2 Total
Read 16Kb Written 16Kb Total transferred 32Kb (21.5Mb/sec)
1376.00 Requests/sec executed

General statistics:
total time: 0.0015s
total number of events: 2
total time taken by event execution: 0.0002s
response time:
min: 0.04ms
avg: 0.10ms
max: 0.15ms
approx. 95 percentile: 0.15ms

Threads fairness:
events (avg/stddev): 0.5000/0.87
execution time (avg/stddev): 0.0000/0.00


9.3.4 多线程小 IO 随机写入性能

[root@tydb010 sysbench]# sysbench --test=fileio --file-num=16 --file-total-size=20M --file-test-mode=rndwr --max-time=120 --file-extra-flags=direct --file-fsync-freq=0 --file-block-size=16384 run
sysbench 0.5: multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1
Random number generator seed is 0 and will be ignored


Extra file open flags: 3
16 files, 1.25Mb each
20Mb total file size
Block size 16Kb
Number of IO requests: 10000
Read/Write ratio for combined random IO test: 1.50
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random write test
Initializing worker threads...

Threads started!

Operations performed: 0 reads, 10000 writes, 16 Other = 10016 Total
Read 0b Written 156.25Mb Total transferred 156.25Mb (103.18Mb/sec)
6603.55 Requests/sec executed

General statistics:
total time: 1.5143s
total number of events: 10000
total time taken by event execution: 1.4883s
response time:
min: 0.09ms
avg: 0.15ms
max: 16.01ms
approx. 95 percentile: 0.24ms

Threads fairness:
events (avg/stddev): 10000.0000/0.00
execution time (avg/stddev): 1.4883/0.00


9.3.5 多线程小 IO 随机读写性能

[root@tydb010 sysbench]# sysbench --test=fileio --file-num=16 --file-total-size=20M --file-test-mode=rndrw --file-extra-flags=direct --file-fsync-freq=0 --file-block-size=16384 run
sysbench 0.5: multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1
Random number generator seed is 0 and will be ignored


Extra file open flags: 3
16 files, 1.25Mb each
20Mb total file size
Block size 16Kb
Number of IO requests: 10000
Read/Write ratio for combined random IO test: 1.50
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads...

Threads started!

Operations performed: 6000 reads, 4000 writes, 16 Other = 10016 Total
Read 93.75Mb Written 62.5Mb Total transferred 156.25Mb (82.04Mb/sec)
5250.54 Requests/sec executed

General statistics:
total time: 1.9046s
total number of events: 10000
total time taken by event execution: 1.8678s
response time:
min: 0.13ms
avg: 0.19ms
max: 14.91ms
approx. 95 percentile: 0.24ms

Threads fairness:
events (avg/stddev): 10000.0000/0.00
execution time (avg/stddev): 1.8678/0.00



9.3.6 清理数据

# sysbench --test=fileio --num-threads=4 --file-total-size=1G --file-test-mode=rndrw cleanup


9.4 CPU 测试

9.4.1 常用参数

[root@tydb010 sysbench]# sysbench --test=cpu help
sysbench 0.5: multi-threaded system evaluation benchmark

cpu options:
--cpu-max-prime=N upper limit for primes generator [10000] # 最大质数发生器数量。默认 10000


9.4.2 数据准备

# sysbench --test=cpu --cpu-max-prime=1000 run
sysbench 0.5: multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1
Random number generator seed is 0 and will be ignored
Prime numbers limit: 1000
Initializing worker threads...
Threads started!
General statistics:
total time: 0.8884s
total number of events: 10000
total time taken by event execution: 0.8848s
response time:
min: 0.06ms
avg: 0.09ms
max: 5.74ms
approx. 95 percentile: 0.12ms

Threads fairness:
events (avg/stddev): 10000.0000/0.00
execution time (avg/stddev): 0.8848/0.00


9.5 线程测试

9.5.1 常用参数

[root@tydb010 sysbench]# sysbench --test=threads help
sysbench 0.5: multi-threaded system evaluation benchmark

threads options:
--thread-yields=N number of yields to do per request [1000] # 每个请求产生多少个线程。默认 1000
--thread-locks=N number of locks per thread [8] # 每个线程的锁的数量。默认 8


9.5.2 测试

# sysbench --test=threads --num-threads=32 --thread-yields=48 --thread-locks=2 run
sysbench 0.5: multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 32
Random number generator seed is 0 and will be ignored

Initializing worker threads...

Threads started!

General statistics:
total time: 1.0757s
total number of events: 10000
total time taken by event execution: 34.3727s
response time:
min: 0.14ms
avg: 3.44ms
max: 1075.43ms
approx. 95 percentile: 0.34ms

Threads fairness:
events (avg/stddev): 312.5000/1206.43
execution time (avg/stddev): 1.0741/0.00


9.6 内存测试

9.6.1 常用参数

[root@tydb010 sysbench]# sysbench --test=memory help
sysbench 0.5: multi-threaded system evaluation benchmark

memory options:
--memory-block-size=SIZE size of memory block for test [1K] # 测试时内存块大小。默认1K
--memory-total-size=SIZE total size of data to transfer [100G] # 传输数据的总大小。默认100G
--memory-scope=STRING memory access scope {global,local} [global] # 内存访问范围{global,local}.默认global
--memory-hugetlb=[on|off] allocate memory from HugeTLB pool [off] # 从 HugeTLB 池内存分配。默认off
--memory-oper=STRING type of memory operations {read, write, none} [write] # 内存操作类型。{read,write,none}。默认write
--memory-access-mode=STRING memory access mode {seq,rnd} [seq] # 存储器存取方式{seq,rnd}。默认seq


9.6.2 测试

# sysbench --test=memory --memory-block-size=8k --memory-total-size=1G run
sysbench 0.5: multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1
Random number generator seed is 0 and will be ignored


Initializing worker threads...

Threads started!

Operations performed: 131072 (441203.19 ops/sec)

1024.00 MB transferred (3446.90 MB/sec)


General statistics:
total time: 0.2971s
total number of events: 131072
total time taken by event execution: 0.2506s
response time:
min: 0.00ms
avg: 0.00ms
max: 0.34ms
approx. 95 percentile: 0.00ms

Threads fairness:
events (avg/stddev): 131072.0000/0.00
execution time (avg/stddev): 0.2506/0.00


10. 测试完后操作

shell> sync --将脏数据刷新到磁盘
shell> echo 3 > /proc/sys/vm/drop_caches --清楚OS Cache
shell> swapoff -a && swapon -a









最后修改时间:2022-05-12 14:58:16
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论