Mysql-经典实战案例（11）：深度解析Sysbench压测（从入门到MySQL服务器性能验证）

news2025/4/1 12:49:03

引言

如何用Sysbench压测满足mysql生产运行的服务器？

Sysbench返回的压测结果如何解读？

别急，本文会教大家如何使用并且如何解读压测的结果信息，如何对mysql服务器进行压测！

一、Sysbench核心功能全景解析

1.1 工具定位与核心模块

Sysbench是集成了多种测试模式的瑞士军刀式压测工具，其模块化架构如下：

模块名称测试方向关键指标应用场景
cpu处理器计算能力Events/s算法类应用验证
memory内存吞吐性能传输速率(MB/s)缓存系统性能评估
fileio存储IO性能IOPS/延迟存储选型验证
oltp数据库事务处理TPS/QPS数据库服务器选型
threads线程调度效率上下文切换耗时高并发应用调优

1.2 下载

# 安装
yum -y install sysbench

# 查看已安装版本
sysbench --version

二、全组件压测参数精解

2.1 CPU性能测试（计算密集型场景）

sysbench cpu \
--cpu-max-prime=20000 \
--threads=4 \
--time=60 \
--events=0 \
run

参数释义：

  • --cpu-max-prime：质数计算范围，越大cpu计算量越大
  • --events=0：不限制事件总数，按时间执行
  • --threads：应与物理核心数一致（非逻辑线程）
  • --time=60：测试持续 60 秒

结果解析：

Prime numbers limit: 20000      # 计算的质数范围
Number of threads: 1547.54            # 并发线程数

CPU speed:
    events per second: 285.74   # 每秒完成的计算次数（越大越好）

General statistics:
    total time: 60.0013s        # 实际总耗时（接近设定的60秒）
    total number of events: 92857  # 60秒内总共完成的计算次数

Latency (ms):
         min: 2.35             # 最快一次计算耗时
         avg: 2.58             # 平均每次计算耗时
         max: 38.4346             # 最慢一次计算耗时
         95th percentile: 2.91 # 95%的计算耗时≤2.91ms

主要关注：CPU speed：events per second: 285.74

  • 直接体现CPU计算吞吐量，数值越高性能越强

2.2 内存性能测试（带宽验证）

sysbench memory \
  --memory-block-size=16K \
  --memory-total-size=5G \
  --memory-oper=write \
  --memory-access-mode=rnd \
  --threads=4 \
  --time=600 \
  run
参数推荐值依据
block-size16K匹配innodb_page_size配置(默认16K)
total-size5G需超过buffer_pool_size(通常设为物理内存75%)
threads16等于物理核心数（双路E5：2×8核）
access-modernd匹配B+树索引访问模式

结果解析：

Total operations: 327680 (82003.29 per second)  总操作次数

5120.00 MiB transferred (1281.30 MiB/sec)   总传输数据量（实际内存带宽(1281.30 MiB/sec））


General statistics:
    total time:                          3.9938s  测试总耗时
    total number of events:              327680   等同于Total operations

Latency (ms):
         min:                                    0.01  最快操作耗时
         avg:                                    0.05  平均延迟
         max:                                    7.14  最慢操作耗时
         95th percentile:                        0.08  95%操作在0.08ms内完成
         sum:                                15604.66  所有操作累计耗时

Threads fairness:
    events (avg/stddev):           81920.0000/0.00   各线程平均操作数
    execution time (avg/stddev):   3.9012/0.05    各线程平均耗时（3.9秒）

主要关注：(1281.30 MiB/sec) 该参数为内存带宽

2.3 存储性能测试（IO混合负载）

准备：
sysbench fileio \
--file-total-size=10G \
--file-test-mode=rndrw \
--file-extra-flags=direct \
--time=300 \
--threads=16 \
prepare


测试：
sysbench fileio \
--file-test-mode=rndrw \
--time=300 \
run

参数释义：

  • --file-test-mode：seqwr/seqrewr/rndrw（随机读写混合IO模式）
  • --file-total-size=10G：总测试文件大小，我这里测试的存储性能比较差，所以文件大小只测10G
  • --file-extra-flags：direct跳过OS缓存，会显著降低速度（绕过缓存），但反映真实磁盘性能
  • --threads=16：并发线程数

结果解析：

在执行prepare命令的时候，通过iostat观察到磁盘的读写情况

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.00    0.00    2.00     0.00     0.03    32.00     0.00    1.50    0.00    1.50   1.50   0.30
sdc               0.00     0.00    0.00    1.00     0.00     0.00     8.00     0.00    1.00    0.00    1.00   1.00   0.10
sdb               0.00     0.00    0.00  582.00     0.00     9.09    32.00     0.97    1.67    0.00    1.67   1.67  97.20
sdd               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
dm-0              0.00     0.00    0.00  585.00     0.00     9.13    31.96     0.98    1.67    0.00    1.67   1.66  97.20
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
dm-2              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
sde               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
sdf               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
设备状态主要负载类型利用率(%util)每秒写操作(w/s)吞吐量(wMB/s)
sdb重度负载顺序小写98.10%4136.45
dm-0重度负载顺序小写98.10%4166.49
核心指标解读
指标值健康阈值问题描述
%util98.1%<70%设备已完全饱和，I/O通道拥塞
w/s413根据设备类型对于HDD偏高，SSD正常偏低
wMB/s6.45-实际带宽利用率低
avgrq-sz32KB-请求碎片化严重（理想≥128KB）
await2.38ms<5ms队列等待时间可控
avgqu-sz0.98<1存在持续排队但未严重堆积

正式测试返回值

File operations:
    reads/s:                      291.59
    writes/s:                     194.39
    fsyncs/s:                     622.10

Throughput:
    read, MiB/s:                  4.56
    written, MiB/s:               3.04

General statistics:
    total time:                          300.2915s
    total number of events:              332743

Latency (ms):
         min:                                    0.00
         avg:                                    0.90
         max:                                  251.79
         95th percentile:                        3.55
         sum:                               299449.80

Threads fairness:
    events (avg/stddev):           332743.0000/0.00
    execution time (avg/stddev):   299.4498/0.00

关键操作指标（基准值为参考范围）

参数数值单位定义性能评价
reads/s291.59次/秒每秒文件读取操作次数中负载水平（SSD典型值：10,000-100,000次/秒，HDD：100-200次/秒）
writes/s194.39次/秒每秒文件写入操作次数存在优化空间（批量写入可提升效率）
fsyncs/s622.10次/秒每秒强制刷盘次数（同步存储介质操作）高危操作（机械硬盘fsync成本极高，易成瓶颈）
read throughput4.56MiB/s数据读取速度低速模式（SSD PCIe4.0理论值5,000MiB/s，HDD≈150MiB/s）
write throughput3.04MiB/s数据写入速度极低吞吐（提示小文件随机写场景）

延迟深度解析（单位：毫秒）

指标数值典型参考值异常状态判别
min latency0.000.01-0.1ms (SSD)直接内存操作场景（page cache命中）
avg latency0.90<1ms (NVMe SSD正常)硬件性能达标，但需关注高频fsync的影响
max latency251.79<100ms (OLTP场景要求)严重超标（可能遭遇机械寻道/坏扇区重试）
95th percentile3.55应类似avg latency存在长尾延迟（5%请求>3.55ms）
总延迟累积299,449.80无直接参考值总延迟≈测试时长（299秒≈300秒），验证系统满载运行

三、MySQL服务器专项验证（实战演练）

3.1 测试环境准备

# 创建专用测试库
mysql -uroot -p -e "CREATE DATABASE sbtest;"


# 生成生产级测试数据
sysbench --threads=16 --time=600 --report-interval=1 --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password=密码 --mysql-db=sbtest --tables=8 --table-size=50000 oltp_read_write prepare

关键参数说明：

  • --table-size：单表5万行（模拟小型数据库）
  • --tables=8：多表结构验证锁竞争（小型数据库标准）
  • oltp_read_write：测试模式：OLTP混合读写

3.2 读写测试

sysbench --threads=16 --time=30 --report-interval=1 --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password=密码 --mysql-db=sbtest --tables=8 --table-size=50000 oltp_read_write run

3.3 测试结果深度解析

SQL statistics:
    queries performed:
        read:                            129626
        write:                           37036
        other:                           18518
        total:                           185180
    transactions:                        9259   (308.34 per sec.)   #关键参数
    queries:                             185180 (6166.89 per sec.)  #关键参数
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          30.0266s
    total number of events:              9259

Latency (ms):
         min:                                   12.06
         avg:                                   51.87
         max:                                 3342.50
         95th percentile:                      108.68   #关键参数
         sum:                               480247.49

Threads fairness:
    events (avg/stddev):           578.6875/4.78
    execution time (avg/stddev):   30.0155/0.01

性能水平：

  • TPS 308.34：表示数据库每秒处理约 308 个事务，吞吐量中等，具体需结合硬件配置评估。
  • 平均延迟 51.87ms：响应时间在合理范围，但 95% 请求 ≤ 108.68ms，最大延迟 3.3 秒，可能存在偶发性能问题（如锁竞争、I/O 瓶颈）。

通过本指南，您将能够：

  1. 全面掌握Sysbench的测试能力
  2. 精准定位服务器性能瓶颈
  3. 验证MySQL服务器承载能力

最终建议：在新服务器上线、配置变更、业务量增长30%时，都应执行全量压力测试。保存历史测试数据，形成性能趋势分析，为容量规划提供数据支撑。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/2324325.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

WebSocket通信的握手阶段

WebSocket通信的握手阶段

1. 客户端建立连接时&#xff0c;通过 http 发起请求报文&#xff0c;报文表示请求服务器端升级协议为 WebSocket&#xff0c;与普通的 http 请求协议略有区别的部分在于如下的这些协议头&#xff1a; 上述两个字段表示请求服务器端升级协议为 websocket 协议。 2. 服务器端响…
阅读更多...
分布式ID服务实现全面解析

分布式ID服务实现全面解析

分布式ID生成器是分布式系统中的关键基础设施&#xff0c;用于在分布式环境下生成全局唯一的标识符。以下是各种实现方案的深度解析和最佳实践。 一、核心需求与设计考量 1. 核心需求矩阵 需求 重要性 实现难点 全局唯一 必须保证 时钟回拨/节点冲突 高性能 高并发场景…
阅读更多...
dom0运行android_kernel: do_serror of panic----failed to stop secondary CPUs 0

dom0运行android_kernel: do_serror of panic----failed to stop secondary CPUs 0

问题描述&#xff1a; 从日志看出,dom0运行android_kernel&#xff0c;刚开始运行就会crash,引发panic 解决及其原因分析&#xff1a; 最终问题得到解决&#xff0c;发现是前期在调试汇编阶段代码时&#xff0c;增加了汇编打印的指令&#xff0c;注释掉这些指令,问题得到解决。…
阅读更多...
HarmonyOS NEXT——【鸿蒙原生应用加载Web页面】

HarmonyOS NEXT——【鸿蒙原生应用加载Web页面】

鸿蒙客户端加载Web页面&#xff1a; 在鸿蒙原生应用中&#xff0c;我们需要使用前端页面做混合开发&#xff0c;方法之一是使用Web组件直接加载前端页面&#xff0c;其中WebView提供了一系列相关的方法适配鸿蒙原生与web之间的使用。 效果 web页面展示&#xff1a; Column()…
阅读更多...
优选算法的慧根之翼：位运算专题

优选算法的慧根之翼：位运算专题

专栏&#xff1a;算法的魔法世界 个人主页&#xff1a;手握风云 一、位运算 基础位运算 共包含6种&(按位与&#xff0c;有0就是0)、|(按位或有1就是1)、^(按位异或&#xff0c;相同为0&#xff0c;相异为1)、~(按位取反&#xff0c;0变成1&#xff0c;1变成0)、<<(左…
阅读更多...
图论问题集合

图论问题集合

图论问题集合 寻找特殊有向图&#xff08;一个节点最多有一个出边&#xff09;中最大环路问题特殊有向图解析算法解析步骤 1 &#xff1a;举例分析如何在一个连通块中找到环并使用时间戳计算大小步骤 2 &#xff1a;抽象成算法注意 实现 寻找特殊有向图&#xff08;一个节点最多…
阅读更多...
【数据结构】栈 与【LeetCode】20.有效的括号详解

【数据结构】栈 与【LeetCode】20.有效的括号详解

目录 一、栈1、栈的概念及结构2、栈的实现3、初始化栈和销毁栈4、打印栈的数据5、入栈操作---栈顶6、出栈---栈顶6.1栈是否为空6.2出栈---栈顶 7、取栈顶元素8、获取栈中有效的元素个数 二、栈的相关练习1、练习2、AC代码 个人主页&#xff0c;点这里~ 数据结构专栏&#xff0c…
阅读更多...
Redis设计与实现-哨兵

Redis设计与实现-哨兵

哨兵模式 1、启动并初始化sentinel1.1 初始化服务器1.2 使用Sentinel代码1.3 初始化sentinel状态1.4 初始化sentinel状态的master属性1.5 创建连向主服务器的网络连接 2、获取主服务器信息3、获取从服务器的信息4、向主从服务器发送信息5、接受主从服务器的频道信息6、检测主观…
阅读更多...
C++进阶——封装哈希表实现unordered_map/set

C++进阶——封装哈希表实现unordered_map/set

与红黑树封装map/set基本相似&#xff0c;只是unordered_map/set是单向迭代器&#xff0c;模板多传一个HashFunc。 目录 1、源码及框架分析 2、模拟实现unordered_map/set 2.1 复用的哈希表框架及Insert 2.2 iterator的实现 2.2.1 iteartor的核心源码 2.2.2 iterator的实…
阅读更多...
【算法day25】 最长有效括号——给你一个只包含 ‘(‘ 和 ‘)‘ 的字符串，找出最长有效（格式正确且连续）括号子串的长度。

【算法day25】 最长有效括号——给你一个只包含 ‘(‘ 和 ‘)‘ 的字符串，找出最长有效（格式正确且连续）括号子串的长度。

32. 最长有效括号 给你一个只包含 ‘(’ 和 ‘)’ 的字符串&#xff0c;找出最长有效&#xff08;格式正确且连续&#xff09;括号子串的长度。 https://leetcode.cn/problems/longest-valid-parentheses/ 2.方法二&#xff1a;栈 class Solution { public:int longestValid…
阅读更多...
Jenkins + CICD流程一键自动部署Vue前端项目（保姆级）

Jenkins + CICD流程一键自动部署Vue前端项目（保姆级）

git仓库地址&#xff1a;参考以下代码完成,或者采用自己的代码。 南泽/cicd-test 拉取项目代码到本地 使用云服务器或虚拟机采用docker部署jenkins 安装docker过程省略 采用docker部署jenkins&#xff0c;注意这里的命令&#xff0c;一定要映射docker路径&#xff0c;否则无…
阅读更多...
一款超级好用且开源免费的数据可视化工具——Superset

一款超级好用且开源免费的数据可视化工具——Superset

认识Superset 数字经济、数字化转型、大数据等等依旧是如今火热的领域&#xff0c;数据工作有一个重要的环节就是数据可视化。 看得见的数据才更有价值&#xff01; 现如今依旧有多数企业号称有多少多少数据&#xff0c;然而如果这些数据只是呆在冷冰冰的数据库或文件内则毫无…
阅读更多...
RedHatLinux(2025.3.22)

RedHatLinux(2025.3.22)

1、创建/www目录&#xff0c;在/www目录下新建name和https目录&#xff0c;在name和https目录下分别创建一个index.htm1文件&#xff0c;name下面的index.html 文件中包含当前主机的主机名&#xff0c;https目录下的index.htm1文件中包含当前主机的ip地址。 &#xff08;1&…
阅读更多...
【C++篇】类与对象（上篇）：从面向过程到面向对象的跨越

【C++篇】类与对象（上篇）：从面向过程到面向对象的跨越

&#x1f4ac; 欢迎讨论&#xff1a;在阅读过程中有任何疑问&#xff0c;欢迎在评论区留言&#xff0c;我们一起交流学习&#xff01; &#x1f44d; 点赞、收藏与分享&#xff1a;如果你觉得这篇文章对你有帮助&#xff0c;记得点赞、收藏&#xff0c;并分享给更多对C感兴趣的…
阅读更多...
智慧运维平台：赋能未来，开启高效运维新时代

智慧运维平台：赋能未来，开启高效运维新时代

在当今数字化浪潮下&#xff0c;企业IT基础设施、工业设备及智慧城市系统的复杂度与日俱增&#xff0c;传统人工运维方式已难以满足高效、精准、智能的管理需求。停机故障、低效响应、数据孤岛等问题直接影响企业运营效率和成本控制。大型智慧运维平台&#xff08;AIOps, Smart…
阅读更多...
基于大语言模型的智能音乐创作系统——从推荐到生成

基于大语言模型的智能音乐创作系统——从推荐到生成

一、引言&#xff1a;当AI成为音乐创作伙伴 2023年&#xff0c;一款由大语言模型&#xff08;LLM&#xff09;生成的钢琴曲《量子交响曲》在Spotify冲上热搜&#xff0c;引发音乐界震动。传统音乐创作需要数年专业训练&#xff0c;而现代AI技术正在打破这一壁垒。本文提出一种…
阅读更多...
Reactive编程：什么是Reactive编程？Reactive编程思想

Reactive编程：什么是Reactive编程？Reactive编程思想

文章目录 **1. Reactive编程概述****1.1 什么是Reactive编程&#xff1f;****1.1.1 Reactive编程的定义****1.1.2 Reactive编程的历史****1.1.3 Reactive编程的应用场景****1.1.4 Reactive编程的优势** **1.2 Reactive编程的核心思想****1.2.1 响应式&#xff08;Reactive&…
阅读更多...
深度剖析：U盘突然无法访问的数据拯救之道

深度剖析：U盘突然无法访问的数据拯救之道

一、引言 在数字化办公与数据存储日益普及的当下&#xff0c;U盘凭借其小巧便携、即插即用的特性&#xff0c;成为了人们工作、学习和生活中不可或缺的数据存储工具。然而&#xff0c;U盘突然无法访问这一棘手问题却时常困扰着广大用户&#xff0c;它不仅可能导致重要数据的丢失…
阅读更多...
蓝桥杯-特殊的三角形（dfs/枚举/前缀和)

蓝桥杯-特殊的三角形（dfs/枚举/前缀和)

思路分析 深度优先搜索&#xff08;DFS&#xff09;思路 定义与参数说明 dfs 函数中&#xff0c;last 记录上一条边的长度&#xff0c;用于保证新选边长度大于上一条边&#xff0c;实现三边互不相等 。cnt 记录已选边的数量&#xff0c;当 cnt 达到 3 时&#xff0c;就构成了…
阅读更多...
一文详解k8s体系架构知识

一文详解k8s体系架构知识

0.云原生 1.k8s概念 1. k8s集群的两种管理角色 Master&#xff1a;集群控制节点&#xff0c;负责具体命令的执行过程。master节点通常会占用一股独立的服务器&#xff08;高可用部署建议用3台服务器&#xff09;&#xff0c;是整个集群的首脑。 Master节点一组关键进程&#xf…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023