1. 从零开始：搞定sysbench的安装与配置

性能测试这事儿，听起来挺高大上，但说白了，就是给你的服务器“跑个分”，看看它到底有几斤几两。无论是新买的云服务器，还是自己攒的数据库集群，在正式上线前，不跑几轮压力测试，心里总是不踏实。这时候，一个靠谱的工具就至关重要了。我折腾过不少性能测试工具，最后发现，sysbench 是那个最朴实、最直接，也最不容易出错的“老伙计”。它就像一把瑞士军刀，CPU、内存、磁盘、数据库，样样都能测，而且命令简单，结果直观。

今天，我就手把手带你从安装开始，一路玩转sysbench的核心测试。别担心，过程一点都不复杂，哪怕你之前没怎么接触过Linux命令行，跟着我的步骤走，也能轻松搞定。咱们先从最基础的安装说起，这里可能会遇到一两个小坑，我都帮你踩过了，照着做就行。

1.1 安装前的准备：获取源码与依赖

sysbench的安装方式有好几种，比如直接用系统包管理器（如 yum 或 apt），但我更推荐从GitHub下载源码编译安装。原因很简单：版本最新，可控性强，能灵活指定安装路径和依赖库。原始文章里给的地址和版本可能有点旧了，咱们直接去GitHub上找最新的稳定版。

首先，找个目录，把源码包下载下来。你可以用 wget 或者 curl，这里以 curl 为例：

# 创建一个临时工作目录，避免把文件下得到处都是
mkdir -p ~/sysbench_src && cd ~/sysbench_src

# 从GitHub下载最新的稳定版源码包（以1.0.20为例，请检查最新版本号）
curl -L -O https://github.com/akopytov/sysbench/archive/refs/tags/1.0.20.tar.gz

# 解压下载的tar包
tar -zxvf 1.0.20.tar.gz

解压后，你会看到一个 sysbench-1.0.20 的目录，这就是我们的源码目录了。在编译之前，系统需要一些基础的编译工具和库文件，这就是所谓的“依赖”。原始文章里提到了 autoconf、automake 和 libtool，这确实是核心的构建工具。但对于不同的Linux发行版，依赖包的名字可能略有不同。

如果你用的是 CentOS、RHEL 或 Fedora 这类基于RPM的系统，安装命令如下：

sudo yum -y install autoconf automake libtool make gcc openssl-devel

如果你用的是 Ubuntu 或 Debian，命令则是：

sudo apt-get update
sudo apt-get install -y autoconf automake libtool make gcc libssl-dev

这里我多加了 gcc（编译器）和 openssl-devel / libssl-dev（SSL开发库），因为后续编译可能会用到，一次性装齐省得麻烦。这一步完成，基础环境就准备好了。

1.2 编译安装与路径配置

进入解压好的源码目录，接下来就是标准的“三板斧”：生成配置脚本、配置编译选项、编译并安装。

cd sysbench-1.0.20/
./autogen.sh

./autogen.sh 这个脚本会生成 configure 文件，这是编译的配置脚本。接着，运行 configure 来定制安装。这里有个关键点：指定MySQL的头文件和库文件路径。如果你后续不打算测试MySQL数据库，可以不关联MySQL。但既然咱们要全面，就一步到位。

假设你的MySQL是通过官方二进制包或源码安装在 /usr/local/mysql 目录下的（这是很常见的自定义安装路径）。那么配置命令可以这样写：

./configure --prefix=/usr/local/sysbench \
            --with-mysql-includes=/usr/local/mysql/include \
            --with-mysql-libs=/usr/local/mysql/lib

我来解释一下这几个参数：

  • --prefix=/usr/local/sysbench： 这指定了sysbench自身的安装目录。我习惯把第三方软件装在 /usr/local/ 下面，管理起来清晰。你可以改成任何你喜欢的路径。
  • --with-mysql-includes： 告诉编译器去哪里找MySQL的头文件（.h文件），这些文件定义了函数接口。
  • --with-mysql-libs： 告诉编译器去哪里找MySQL的库文件（.so文件），这些是编译时链接的实际代码。

配置成功后，就可以编译和安装了：

make
sudo make install

make 过程可能会花几分钟，取决于你机器的性能。sudo make install 会把编译好的程序、脚本等文件，复制到之前 --prefix 指定的目录（/usr/local/sysbench）下。

1.3 验证安装与解决“经典”库错误

安装完成后，第一件事就是验证是否成功。进入安装目录的 bin 子目录，运行版本检查命令：

/usr/local/sysbench/bin/sysbench --version

如果一切顺利，你会看到类似 sysbench 1.0.20 的版本信息输出。但是，十有八九你会遇到一个经典错误，这也是原始文章里重点提到的问题：

sysbench: error while loading shared libraries: libmysqlclient.so.18: cannot open shared object file: No such file or directory

别慌，这个错误我见过太多次了。它的意思是：系统在运行时（注意，不是编译时）找不到MySQL的客户端库文件 libmysqlclient.so.18。编译时我们通过 --with-mysql-libs 告诉了编译器库在哪，但系统加载器（ld）并不知道这个路径。

解决思路就是让系统知道这个库文件的位置。原始文章提供了两种方法，我这里合并优化一下，提供一个更通用的方案：

第一步，确认库文件的确切位置和版本。 进入你MySQL的lib目录看看：

ls -lh /usr/local/mysql/lib/libmysqlclient.so*

你可能会看到 libmysqlclient.so.21 或 libmysqlclient.so.20，版本号可能不同。记住这个完整的文件名。

第二步，建立软链接到系统库目录。 系统通常会在 /usr/lib 或 /usr/local/lib 目录下寻找共享库。我们把MySQL的库文件链接过去：

# 将实际的库文件链接到 /usr/local/lib 下，使用你查看到的真实文件名
sudo ln -s /usr/local/mysql/lib/libmysqlclient.so.21 /usr/local/lib/

注意，这里只链接了库文件本身，没有带版本号后缀。系统加载器会自己去找带版本号的那个。

第三步，更新系统库缓存。 告诉系统我们新加了一个库路径，运行：

sudo ldconfig

现在，再次尝试运行版本检查命令：

/usr/local/sysbench/bin/sysbench --version

这次，你应该能看到成功的版本输出了！恭喜你，sysbench已经整装待发。为了方便使用，我建议你把sysbench的可执行文件路径加入系统的 PATH 环境变量，这样在任何目录下都能直接输入 sysbench 命令了。

echo 'export PATH=/usr/local/sysbench/bin:$PATH' >> ~/.bashrc
source ~/.bashrc

现在，直接在命令行输入 sysbench --version 试试吧！

2. 初试锋芒：CPU与内存性能测试详解

安装配置搞定，咱们就进入实战环节。先从最简单的CPU和内存测试开始，这两个测试不依赖外部服务，跑起来最快，能立刻给你一个关于机器计算能力和内存带宽的直观感受。很多人觉得跑分就是看个数字，其实不然，通过调整参数观察变化，你能深刻理解硬件特性和软件负载之间的关系。

2.1 CPU性能测试：不只是看主频

运行一个最基本的CPU测试只需要一行命令：

sysbench cpu run

这个命令会让sysbench计算素数（质数）一直到某个值（默认是10000），通过计算所需的时间来评估CPU的整数运算能力。你会看到类似下面的输出，里面包含了总时间、每秒事件数等关键指标。

CPU speed:
    events per second:  1234.5678

但是，直接 run 用的是默认参数，可能不够“刺激”。我们可以通过一些选项来定制测试，让它更贴合你的实际场景。最常用的两个参数是 --cpu-max-prime 和 --threads。

--cpu-max-prime 定义了计算素数的上限。数值越大，计算量越大，测试时间越长，对CPU的压力也越大。比如，你想来一次重度计算测试：

sysbench cpu --cpu-max-prime=200000 --threads=1 run

这里我故意只用了1个线程，是为了测试单核的纯粹计算性能。你可以观察CPU使用率（用 top 命令），应该能看到一个核心被跑满。

而 --threads 参数就更有趣了，它用来指定并发线程数。现代服务器都是多核CPU，这个参数能帮你测试CPU的多核并行计算能力。我们来对比一下：

# 测试1：单线程
sysbench cpu --threads=1 run

# 测试2：线程数等于CPU核心数（假设是4核）
sysbench cpu --threads=4 run

# 测试3：线程数超过CPU核心数
sysbench cpu --threads=8 run

跑完这三组测试，重点对比 “events per second”（每秒事件数） 这个指标。理想情况下，从 --threads=1 到 --threads=4，每秒事件数应该接近线性增长（比如从1000增长到3800）。这证明你的CPU多核调度效率不错。当线程数增加到8，如果每秒事件数没有显著提升甚至下降，说明超出了物理核心的并行能力，线程切换带来了额外开销。这个测试能帮你判断，你的应用是更吃单核性能，还是能很好地利用多核并行。

2.2 内存性能测试：带宽与延迟的博弈

内存测试关注的是数据读写的速度。命令也很简单：

sysbench memory run

默认情况下，它会分配总大小为100G的内存块（通过 --memory-total-size 指定，默认100G），然后以1KB的块大小（通过 --memory-block-size 指定，默认1K）进行连续的读写操作，直到达到总数据量。

这里有两个参数对测试结果影响巨大，理解它们你就能自己设计测试场景了：

  • --memory-block-size： 每次操作的内存块大小。设为 1K、4K、1M、10M，测试结果会天差地别。小块（如4K）测试的是内存操作的延迟和CPU内存控制器的效率；大块（如10M）测试的是内存的绝对带宽。 就像用勺子舀水和用水管抽水的区别。
  • --memory-total-size： 测试总共要读写的数据量。这个值必须大于 --memory-block-size。如果你只是想快速验证，可以设小一点，比如 1G。
  • --memory-oper： 指定操作类型，是 write（只写）、read（只读）还是 read（默认，其实是读写混合）。

我来设计两个典型的对比测试场景：

场景一：模拟高并发小对象访问（如缓存） 这种场景下，每次存取的数据块不大，更关心每秒能进行多少次操作。

sysbench memory --memory-block-size=4K --memory-total-size=20G --memory-access-mode=rnd run

这里我加了 --memory-access-mode=rnd 参数，表示随机访问，这比默认的顺序访问（seq）对内存子系统压力更大，更能模拟真实缓存场景。结果中你要重点关注 “Operations per second”。

场景二：测试内存最大吞吐带宽（如大数据处理） 这种场景关心的是在短时间内能搬运多少数据。

sysbench memory --memory-block-size=10M --memory-total-size=50G --threads=8 run

我把块大小设为10M，并启用8个线程并行搬运数据。这时结果中的 “MiB transferred” 和 “MiB/s” 就是核心指标，这个数字应该接近你内存的理论带宽（可以在主板或CPU规格书中查到）。如果远低于理论值，可能意味着内存是单通道而非双通道，或者频率没有达到标称值。

跑完测试后，sysbench会输出详细的读写速度和延迟信息。别忘了，内存测试是纯内存操作，不受磁盘影响，所以结果应该非常稳定。如果多次测试波动很大，那可能需要检查一下是不是有后台进程在干扰，或者内存本身（尤其是在虚拟机上）是不是被过度共享了。

3. 重头戏：磁盘I/O性能测试实战

磁盘I/O（输入/输出）性能是决定数据库、文件服务器等应用表现的关键瓶颈。CPU再快，内存再大，如果数据卡在磁盘读写上，整体性能也会大打折扣。sysbench的fileio测试模块，就是用来模拟真实I/O负载的利器。它比简单的 dd 命令更贴近应用场景，因为它可以模拟多线程、随机读写、同步/异步IO等复杂情况。

3.1 测试前的准备：创建测试文件

磁盘测试需要一个或多个测试文件作为读写对象。第一步不是直接 run，而是 prepare（准备）。这个阶段会在你指定的目录下，创建指定大小和数量的测试文件。

一个典型的准备命令如下：

sysbench fileio --file-total-size=10G --file-num=8 --file-test-mode=rndrw prepare

我来拆解一下这几个参数：

  • --file-total-size=10G： 所有测试文件的总大小。我设为10G，对于快速测试足够了。如果是测试生产环境的大容量SSD或硬盘阵列，可以增加到100G甚至更大，以避免文件被缓存到内存影响结果。
  • --file-num=8： 创建的文件数量。创建多个小文件（比如8个1.25G文件）和创建单个大文件（1个10G文件），测试的I/O模式是不同的。多文件更适合模拟多表数据库或Web服务器存放大量小文件的场景。
  • --file-test-mode=rndrw： 这是核心参数，定义了测试模式。rndrw 表示随机读写。这是对磁盘最严苛的测试模式，因为磁头需要频繁寻道（机械硬盘）或主控需要处理分散的地址（固态硬盘）。其他常用模式还有：
    • seqwr： 顺序写入
    • seqrewr： 顺序重写（先写后读）
    • seqrd： 顺序读取
    • rndrd： 随机读取
    • rndwr： 随机写入

执行 prepare 后，sysbench会在当前目录下生成一堆类似 test_file.0、test_file.1 的文件。务必注意： 请确保当前目录所在的磁盘分区，有足够的剩余空间（大于 --file-total-size），否则会失败。

3.2 执行测试与解读关键指标

准备完成后，就可以运行真正的I/O压力测试了：

sysbench fileio --file-test-mode=rndrw --file-num=8 --threads=16 --time=120 --report-interval=10 run

这个命令比准备阶段多了几个运行时参数：

  • --threads=16： 并发线程数。这是制造压力的关键。对于高性能NVMe SSD，我经常用16甚至32个线程来“喂饱”它。对于机械硬盘，线程数过多反而可能因频繁的寻道竞争导致性能下降，可以从4或8开始试。
  • --time=120： 测试持续时间，单位秒。测试时间太短可能无法反映稳定状态下的I/O性能，建议至少60秒以上。
  • --report-interval=10： 每10秒输出一次中间统计信息。这个非常有用，你可以看到性能是否稳定。如果一开始速度很高，后面骤降，可能是磁盘缓存用尽或者触发了SSD的限速机制。

命令运行后，你会看到瀑布般刷新的数据。别眼花，我们主要关注测试结束后汇总报告里的这几项：

  • IOPS： 每秒的I/O操作次数。这是衡量随机读写性能的黄金指标，尤其是对于数据库这类小块随机读写密集的应用。这个值越高越好。
  • 吞吐量（Throughput）： 通常以 MB/s 显示。对于大文件顺序读写（如视频处理、备份）的场景，这个指标比IOPS更重要。
  • 延迟（Latency）： 包括平均延迟（avg）、95%延迟（95th percentile）和最大延迟（max），单位通常是毫秒（ms）。95%延迟尤其重要，它表示95%的请求都能在这个时间内完成，能很好地反映用户体验是否“平滑”。偶尔的尖峰高延迟（看max）可能是由垃圾回收（GC）或系统调度引起的。

举个例子，如果你测试的是一块SATA SSD，在随机读写模式下，IOPS能达到几万，延迟在几毫秒以内，就算不错。如果是一块高性能NVMe SSD，IOPS应该轻松达到几十万甚至上百万，延迟在百微秒级别。

3.3 清理与进阶测试思路

测试完成后，一定要记得清理测试文件，释放磁盘空间：

sysbench fileio --file-num=8 cleanup

掌握了基础测试后，你可以尝试更复杂的组合，来模拟真实业务：

  1. 不同IO模式对比： 分别用 seqrd、seqwr、rndrd、rndwr 跑一遍，你就能画出一张磁盘的“能力象限图”，清楚知道它的长处和短板。
  2. 测试IO深度的影响： 通过 --file-io-mode 参数（虽然sysbench 1.0对此参数支持有限，更多是通过线程数模拟），或者结合 --file-extra-flags=direct 使用直接IO绕过系统缓存，来测试磁盘在更高队列深度下的表现。
  3. 结合fio工具： 对于更专业、更复杂的I/O场景模拟（如指定IO大小分布、读写比例），业界更常用的工具是 fio。你可以用sysbench做快速验证和对比，用fio做深度调优和极限测试。我个人的经验是，sysbench的fileio测试上手更快，而fio的配置更灵活、更强大。

4. 终极挑战：数据库性能压测实战（以MySQL为例）

压测数据库，是sysbench最经典、也是最能体现其价值的场景。它能够模拟多线程的OLTP（在线事务处理）负载，比如订单处理、用户注册、支付流水等，这对评估数据库服务器的真实处理能力至关重要。原始文章给出了一个基本的命令，但实际应用中，我们需要考虑更多细节，比如避免网络瓶颈、理解测试模型、正确解读结果。

4.1 准备测试数据：构建真实的压力环境

压测的第一步是准备数据。你不能用空库来压测，那样测出来的是缓存性能，毫无意义。sysbench的 oltp_read_write 脚本（这是最常用的综合读写测试模型）会创建一系列表，并填充随机数据。

一个完整的准备命令如下：

sysbench oltp_read_write \
  --db-driver=mysql \
  --mysql-host=localhost \
  --mysql-port=3306 \
  --mysql-user=sbtest \
  --mysql-password=YourStrongPassword123! \
  --mysql-db=sbtest \
  --tables=16 \
  --table-size=1000000 \
  --report-interval=2 \
  prepare

这里每个参数都很有讲究：

  • --db-driver=mysql： 指定数据库驱动，也支持pgsql（PostgreSQL）。
  • --mysql-host： 如果数据库就在本机，强烈建议使用 localhost 或 127.0.0.1，而不是远程IP，这样可以排除网络延迟对测试结果的干扰。这是很多新手容易忽略的一点，网络很可能成为瓶颈，让你误以为数据库性能不行。
  • --mysql-port、--mysql-user、--mysql-password： 连接信息。安全提示： 尽量不要在命令中直接写密码，可以用 --mysql-password=（等号后留空）然后在提示符下输入，或者使用配置文件。我这里为了演示方便写了出来，生产环境切勿这样做。
  • --mysql-db=sbtest： 指定用于测试的数据库名。请提前创建好这个数据库：CREATE DATABASE sbtest; 并确保测试用户有所有权限。
  • --tables=16： 创建16张测试表。多表可以模拟分布式查询，也能减少单表的锁竞争。对于多核服务器，建议表数量至少等于CPU核心数。
  • --table-size=1000000： 每张表插入100万行数据。数据量要足够大，确保测试时大部分读操作能命中磁盘而非内存缓存，这样才能反映真实压力下的性能。对于内存很大的服务器，这个值要相应调高。
  • --report-interval=2： 准备数据时每2秒报告一次进度。准备1000万行以上数据可能需要较长时间，这个参数让你知道进展。

执行 prepare 后，sysbench会开始建表、插数据。这个过程可能会比较慢，耐心等待。完成后，你可以登录MySQL，查看 sbtest 数据库，里面应该有16张名为 sbtest1 到 sbtest16 的表。

4.2 执行压测：模拟真实并发负载

数据准备好后，就可以开始真正的压力测试了：

sysbench oltp_read_write \
  --db-driver=mysql \
  --mysql-host=localhost \
  --mysql-user=sbtest \
  --mysql-password=YourStrongPassword123! \
  --mysql-db=sbtest \
  --tables=16 \
  --table-size=1000000 \
  --threads=32 \
  --time=300 \
  --report-interval=10 \
  run

这次我们引入了几个核心的压测参数：

  • --threads=32： 并发连接数。这是制造数据库压力的关键。你可以从8、16、32、64、128逐步增加，观察数据库的QPS（每秒查询数）和响应时间的变化曲线。当线程数增加到某个点后，QPS不再增长甚至下降，响应时间急剧上升，这个点可能就是数据库的当前配置下的并发拐点。
  • --time=300： 压测持续时间，300秒即5分钟。时间太短可能无法让数据库进入稳定状态（比如InnoDB缓冲池预热完成），建议至少3-5分钟。
  • --report-interval=10： 运行时每10秒输出一次概要统计。通过这个，你可以观察性能是否平稳。如果出现QPS持续下降、延迟持续上升，可能意味着数据库出现了锁等待、慢查询堆积等问题。

运行命令后，sysbench会疯狂地向你的MySQL数据库发送读写请求。你的终端上会刷出实时统计信息。压测结束后，会生成一份详细的汇总报告。

4.3 解读结果与性能瓶颈分析

压测报告的末尾是精华所在，你需要重点关注这几组数据：

  1. SQL统计：

    SQL statistics:
    queries performed:
        read:                            1581234
        write:                           451781
        other:                           225890
        total:                           2258905
    transactions:                        112945 (376.48 per sec.)
    queries:                             2258905 (7529.69 per sec.)
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)
    • transactions ... per sec： TPS（每秒事务数），这是衡量数据库综合处理能力的核心指标。上面的例子是376.48 TPS。
    • queries ... per sec： QPS（每秒查询数），包含了事务内的所有读、写、其他语句。例子中是7529.69 QPS。
    • ignored errors： 被忽略的错误数。如果这里不为0，说明有SQL执行失败了，需要去数据库错误日志里查原因。

  2. 延迟统计：

    Latency (ms):
     min:                                    4.33
     avg:                                   84.97
     max:                                 1452.05
     95th percentile:                      168.21
    • avg： 平均响应时间。例子中是85ms。
    • 95th percentile： 95%请求的响应时间。这个值比平均响应时间更有参考价值，因为它能过滤掉偶发的极端慢请求。例子中是168ms，意味着95%的请求都在168ms内完成。这是评估用户体验是否流畅的关键指标。

  3. 线程公平性：

    Threads fairness:
    events (avg/stddev):           3529.5312/42.84
    execution time (avg/stddev):   300.0004/0.00
    • stddev（标准差）： 反映了不同线程执行事件数和时间的离散程度。标准差越小，说明负载越均衡，没有出现某些线程“饿死”的情况。

如何根据结果找瓶颈？

  • 如果TPS/QPS上不去，但CPU使用率很低： 瓶颈可能在磁盘I/O（看磁盘监控iostat），或者数据库配置不当（如innodb_buffer_pool_size太小）。
  • 如果TPS/QPS上不去，且CPU使用率很高（特别是系统态sy高）： 可能遇到了锁竞争，或者上下文切换开销太大。
  • 如果95%延迟很高，但平均延迟不高： 说明有少数请求特别慢，可能是遇到了行锁等待、慢查询，或者磁盘有偶尔的卡顿。

4.4 清理与更多测试模型

压测完成后，别忘了清理测试数据，恢复环境：

sysbench oltp_read_write --mysql-host=localhost --mysql-user=sbtest --mysql-db=sbtest cleanup

除了最常用的 oltp_read_write（读写混合），sysbench还提供了其他专门化的测试脚本，用于针对性地测试某一方面的能力：

  • oltp_read_only： 纯读测试，模拟报表查询、数据展示等场景。
  • oltp_write_only： 纯写测试，模拟数据采集、日志写入等场景。
  • oltp_point_select： 主键点查询测试，非常考验索引效率。
  • oltp_update_index 和 oltp_update_non_index： 分别测试更新带索引和不带索引字段的性能。
  • select_random_points 和 select_random_ranges： 测试随机范围查询。

你可以通过 sysbench --test=<脚本名> help 来查看每个脚本支持的参数。我的习惯是，先用 oltp_read_write 做一个全面的压力测试，找到大致瓶颈范围后，再用更细分的脚本去精确打击、验证猜想。比如，如果怀疑是磁盘写入慢，就单独跑一下 oltp_write_only；如果怀疑索引效率低，就多跑跑 oltp_point_select。

数据库压测是个系统工程，sysbench给出了一个标准化的“考题”。真正的功夫在于，如何根据“考试成绩”（测试结果），结合数据库监控（如MySQL的SHOW ENGINE INNODB STATUS、SHOW PROCESSLIST）、操作系统监控（top、vmstat、iostat），去分析、调整数据库配置（如InnoDB缓冲池大小、日志文件大小、并发连接数），然后再次测试，形成“测试-分析-调优-再测试”的闭环。这个过程，才是性能测试的价值所在。我经历过好几次，仅仅调整一个参数，就让TPS提升了30%以上，那种成就感，比单纯跑出一个高分要实在得多。

Logo
乐奇 Rokid 开放社区

更多推荐

cover

一期一会 | 什么是抬头显示器（HUD）？

avatar 乐奇 Rokid 开放社区
cover

极刻觅镜 | AI眼镜周报｜Rokid四款硬件发布与Android XR工具转稳定版

avatar 乐奇 Rokid 开放社区
cover

极刻觅镜 | AI眼镜日报｜京东智能眼镜西安站活动与千问AI眼镜OTA升级

avatar 乐奇 Rokid 开放社区