Linux性能测试：stress与sysbench实战教程

本篇文章主要是结合我之前面试的各种经历和实战开发中遇到的问题解决经验整理的，希望这篇《Linux性能测试：stress与sysbench实用指南》对你有很大帮助！欢迎收藏，分享给更多的需要的朋友学习~

Linux系统性能基准测试主要依赖stress和sysbench工具，1.stress适用于快速施加极限负载以验证系统稳定性、定位资源瓶颈、测试散热及服务预热；2.sysbench则用于模拟真实应用场景，提供数据库、文件I/O、CPU和内存的详细性能指标，支持深入分析系统表现；3.关键指标包括CPU利用率、内存使用、磁盘I/O性能、系统平均负载、网络I/O及上下文切换，需结合基线数据综合判断性能瓶颈。

Linux系统性能基准测试，主要可以依赖像stress和sysbench这类工具。stress简单直接，适合快速给系统组件加压，观察其在极限负载下的表现；而sysbench则更侧重于模拟真实应用场景，比如数据库操作或文件I/O，提供更细致的性能数据，帮助我们深入分析瓶颈。

解决方案

进行Linux系统性能基准测试，通常会组合使用不同的工具来达到目的。

stress工具的应用

stress是一个非常直接的工具，用于对系统组件（CPU、内存、I/O、磁盘）施加压力。它的好处是安装简单，使用直观，能迅速模拟某种特定的负载类型。

安装stress：

# Debian/Ubuntu
sudo apt update
sudo apt install stress

# CentOS/RHEL
sudo yum install epel-release
sudo yum install stress

stress常用示例：

• CPU压力测试： 运行4个CPU密集型进程，持续300秒。

  stress --cpu 4 --timeout 300s

  这会把CPU利用率推到很高，观察系统是否稳定，散热是否正常。

• 内存压力测试： 分配2GB内存，并保持占用。

  stress --vm 1 --vm-bytes 2G --timeout 300s

  看系统在内存紧张时，是否开始大量使用SWAP，或者应用程序响应变慢。

• I/O压力测试： 运行2个I/O密集型进程。

  stress --io 2 --timeout 300s

  这会频繁进行磁盘读写操作，观察磁盘I/O性能。

• 混合压力测试： 结合CPU、内存、I/O和磁盘写入。

  stress --cpu 2 --vm 1 --vm-bytes 1G --io 1 --hdd 1 --timeout 600s

  这能模拟一个更复杂的负载场景。

sysbench工具的应用

sysbench是一个更全面的基准测试工具，它支持测试CPU、内存、文件I/O以及数据库（MySQL、PostgreSQL等）的性能。它的优势在于能够提供更详细的性能指标，比如每秒操作数、延迟分布等。

安装sysbench：

# Debian/Ubuntu
sudo apt update
sudo apt install sysbench

# CentOS/RHEL
sudo yum install epel-release
sudo yum install sysbench

sysbench常用示例：

• CPU性能测试： 计算指定大小的素数，评估CPU的单核或多核计算能力。

  sysbench cpu run --cpu-max-prime=20000

  --cpu-max-prime的值越大，测试时间越长，对CPU的压力也越大。

• 内存性能测试： 模拟内存读写操作，评估内存带宽和延迟。

  sysbench memory run --memory-block-size=1M --memory-total-size=4G

  这里指定了每次读写1MB块，总共操作4GB内存。

• 文件I/O性能测试： 模拟文件读写，可以测试顺序读写、随机读写等。 首先，准备测试文件：

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

  然后，运行测试：

  sysbench fileio run --file-total-size=10G --file-test-mode=rndrw --time=300 --threads=8

  最后，清理测试文件：

  sysbench fileio cleanup --file-total-size=10G

  --file-test-mode可以选择seqrd（顺序读）、seqwr（顺序写）、rndrd（随机读）、rndwr（随机写）、rndrw（随机读写）。

stress工具在哪些场景下能发挥最大作用？

在我看来，stress这个工具的价值，更多体现在它那份“粗暴直接”上。它不是为了给你一个精确到小数点后几位的性能报告，而是让你快速摸清系统在某种极限条件下的“脾气”。比如，当你刚更换了CPU散热器，或者升级了内存条，想快速验证一下系统在高负载下是否依然稳定，会不会过热死机，stress就能派上大用场。

它特别适合做：

• 快速稳定性验证： 比如部署新服务器，或者虚拟机迁移后，用stress --cpu $(nproc) --timeout 60s跑一下，看看系统有没有立刻崩溃，或者负载飙升到不合理的高度。这就像开车前先踩几脚油门，听听发动机有没有异响。
• 资源瓶颈的初步定位： 如果你怀疑是CPU不够用，或者内存泄漏，可以单独用stress --cpu或stress --vm去压，同时用top、htop、vmstat观察，很快就能看到哪个资源被吃满了，这能帮你缩小排查范围。它不会告诉你具体是哪个应用出了问题，但能告诉你“CPU快顶不住了”或者“内存吃紧了”。
• 散热测试： 跑一个长时间的CPU和内存压力测试，结合sensors命令或者主板监控工具，看看CPU温度和主板温度会不会过高。这对于物理服务器来说尤其重要，能避免潜在的硬件故障。
• 服务上线前的“预热”： 有些应用在冷启动后性能不佳，需要预热缓存。虽然stress不是专门为此设计，但它能通过模拟负载，间接让系统的一些缓存机制活跃起来，或者提前暴露一些不稳定的因素。

当然，stress的局限性也很明显，它生成的负载是高度合成的，和真实世界中的应用负载往往有很大差异。它模拟的I/O模式也比较简单。所以，它更像是一个“烟雾测试”工具，而非精密的测量仪器。

sysbench与stress相比，它更适合进行哪类深入的性能分析？

如果说stress是那种简单粗暴的“体力活”，那么sysbench就更像一个精密的“外科手术刀”。它的设计哲学决定了它能深入到更复杂的应用场景中去，提供远超stress的细粒度数据。

sysbench最出彩的地方在于它对数据库性能的模拟。它能生成各种SQL语句，包括SELECT、INSERT、UPDATE、DELETE，甚至复杂的事务（OLTP），来模拟真实世界的数据库负载。这对于数据库管理员、开发者来说简直是神器。你可以用它来：

• 数据库容量规划： 比如，我想知道我的MySQL服务器在每秒处理1000个事务时，CPU、内存、磁盘I/O的表现如何。sysbench的OLTP测试能给出非常详细的TPS（Transactions Per Second）、QPS（Queries Per Second）以及各种延迟百分位数，这些数据直接关系到数据库的承载能力。
• 不同数据库版本或配置的对比： 升级了MySQL 8.0，或者调整了innodb_buffer_pool_size，性能是提升了还是下降了？跑个sysbench的OLTP测试，数据一对比就清晰了。
• 存储系统性能评估： sysbench的文件I/O测试，可以模拟随机读写、顺序读写，并指定文件大小、块大小、线程数。这比stress简单的--hdd要精细得多。比如，我想知道我的SSD在4KB随机读写下的IOPS是多少，延迟又是多少，sysbench能直接给出这些关键指标，这对于评估存储阵列、选择文件系统或者优化数据库存储布局非常有帮助。
• 更精确的CPU和内存基准： 尽管stress也能压CPU和内存，但sysbench的CPU测试通过计算素数来衡量整数运算能力，内存测试则能模拟更复杂的内存访问模式，并提供吞吐量（MB/s）和延迟数据，这对于评估特定计算任务或内存密集型应用的性能更有参考价值。

sysbench输出的结果通常包含平均值、最大值、最小值、标准差，以及关键的95%或99%分位延迟，这些统计数据能让你更全面地理解系统在负载下的行为，而不是仅仅知道它“跑得快不快”，还能知道它“稳不稳定”、“有没有突然卡顿”。

进行Linux系统性能基准测试时，有哪些关键指标需要关注？

做性能基准测试，跑完工具只是第一步。更重要的是，你要知道看什么、怎么看，才能真正理解系统的表现。这就像你体检完拿到一堆报告，得知道哪些指标是健康的，哪些是需要关注的。

以下是我在进行Linux系统性能基准测试时，会特别留意的几个关键指标：

1. CPU利用率（CPU Utilization）：

   • User/System： 用户态CPU（执行应用程序代码）和内核态CPU（执行系统调用、驱动等）。如果User高，说明应用程序计算量大；如果System高，可能说明系统调用频繁或驱动有问题。
   • Idle： 空闲CPU百分比。如果负载测试时Idle还很高，说明负载不够，或者瓶颈不在CPU。
   • I/O Wait： CPU等待I/O操作完成的时间。这个值高了，通常意味着磁盘或网络I/O是瓶颈。
   • 工具： top, htop, vmstat, sar, mpstat

2. 内存使用情况（Memory Usage）：

   • Used/Free： 已用和空闲内存。
   • Buffers/Cache： Linux内核用于缓存磁盘I/O的内存，这部分通常是可回收的。
   • Swap Usage： 交换空间使用情况。如果测试过程中Swap使用量激增，甚至出现Swap In/Out，那说明物理内存不足，系统性能会急剧下降。
   • 工具： free -h, vmstat, top

3. 磁盘I/O性能（Disk I/O Performance）：

   • IOPS (Input/Output Operations Per Second)： 每秒读写操作次数。衡量磁盘处理小文件随机读写的能力。
   • Throughput (MB/s)： 每秒读写数据量。衡量磁盘处理大文件顺序读写的能力。
   • Latency： 每次I/O操作的响应时间。这个值越低越好。
   • Utilization (%)： 磁盘忙碌的百分比。如果长时间接近100%，说明磁盘是瓶颈。
   • Queue Length： 磁盘I/O队列的长度，等待处理的I/O请求数量。
   • 工具： iostat -x 1, fio (更专业的磁盘测试工具)

4. 系统平均负载（Load Average）：

   • 通常显示为1分钟、5分钟、15分钟的平均值。它代表了等待CPU运行的进程数加上正在运行的进程数。
   • 一个经验法则是，负载平均值不应超过CPU核心数。如果一个8核CPU的服务器，负载平均值长期在15以上，那说明系统已经过载了。
   • 工具： uptime, top, htop

5. 网络I/O（Network I/O）：

   • Rx/Tx Bytes/Packets： 接收和发送的字节数/包数。
   • Errors/Drops： 网络接口上的错误包和丢弃包数量。这些通常预示着网络硬件或配置问题。
   • 工具： netstat -s, sar -n DEV, iftop

6. 上下文切换（Context Switches）：

   • 进程或线程从一个执行上下文切换到另一个执行上下文的次数。过高的上下文切换可能意味着CPU在忙于调度而不是执行实际工作，这通常发生在大量线程竞争CPU资源时。
   • 工具： vmstat -w 1, pidstat -w

在分析这些指标时，我通常会先建立一个基线（Baseline）。也就是说，在没有任何负载的情况下，记录下这些指标的正常值。然后，在运行基准测试时，对比这些值，看它们如何变化。异常的峰值、持续的高利用率，或者某个指标突然偏离正常范围，都可能是性能瓶颈的信号。同时，单一指标往往不能说明问题，需要结合多个指标进行综合判断。比如，CPU的I/O Wait高，同时磁盘的Utilization也高，那基本就能确定是磁盘I/O拖了后腿。

到这里，我们也就讲完了《Linux性能测试：stress与sysbench实战教程》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！