Linux服务器压力测试实战：用stress工具模拟高负载场景（附常用参数解析）

莫同

456人浏览 · 2026-03-03 01:50:54

莫同 · 2026-03-03 01:50:54 发布

Linux服务器压力测试实战：用stress工具模拟高负载场景（附常用参数解析）

最近在排查一个线上服务间歇性卡顿的问题时，我再次深刻体会到，没有经过压力测试验证的容量规划，无异于一场赌博。很多运维和开发朋友习惯用“感觉”来评估服务器性能，比如“这台机器配置挺高的，应该没问题”。但真实的高并发请求、突发的数据处理任务，或是某个异常进程的内存泄漏，往往会在你最意想不到的时候，给系统带来致命一击。这时候，一个能主动“制造麻烦”的工具，就成了我们提前发现系统脆弱点的得力助手。

今天要深入聊的，就是Linux系统下这个看似简单却威力十足的stress工具。它不像那些功能庞杂、图表华丽的商业压测套件，stress的核心哲学极其纯粹：用最直接的方式，对系统的CPU、内存、磁盘I/O等核心资源施加可控的压力。你可以把它理解为一个“系统压力模拟器”，通过它，我们可以在受控的环境下，观察服务器在极限负载下的表现，比如CPU使用率是否真的能跑满、内存不足时系统的交换（swap）行为、磁盘IO延迟激增对应用的影响等等。这对于计划上线新服务、评估硬件扩容方案，或是单纯想了解自己服务器“抗压底线”的运维工程师和开发者来说，是一项必备的、低成本的核心技能。

1. 理解压力测试的本质与stress的定位

在开始敲命令之前，我们有必要先统一认知：我们为什么要做压力测试？ 很多人可能会脱口而出：“为了看服务器能承受多少流量。”这个答案对，但不完全对。更精确地说，压力测试（Stress Testing）的目标是评估系统在极端或超出正常负载条件下的稳定性、可靠性和性能表现。它关注的是“破坏性”场景：当CPU持续100%运转一分钟、五分钟甚至一小时，系统服务会变慢还是直接崩溃？当物理内存被耗尽，开始频繁使用swap时，应用的响应时间会恶化到什么程度？

stress正是为此而生。它不模拟复杂的业务逻辑（那是ab、wrk或jmeter的领域），而是专注于制造基础资源层面的压力源。它的工作模式是启动多个“压力工人”（worker），每个工人执行特定的、高度消耗资源的操作。这种设计的巧妙之处在于，它剥离了业务复杂性，让我们能清晰地看到硬件资源和操作系统内核在纯粹压力下的表现，这为后续更复杂的、结合业务场景的压测奠定了坚实的基础。

提示：将stress视为你服务器体检中的“负荷心电图”测试。它通过施加标准化的“运动量”（压力），来揭示系统在平静状态下无法暴露的潜在问题，如散热不足、电源功率瓶颈或内存控制器缺陷。

1.1 stress工具的核心能力与适用场景

stress主要能模拟三种类型的压力，几乎涵盖了服务器性能瓶颈的主要方面：

CPU压力：创建多个进程，每个进程持续进行浮点运算（如计算平方根），旨在让CPU的执行单元（尤其是浮点运算单元）保持高占用率。
内存压力：动态分配和释放指定大小的内存块，可以模拟内存占用、频繁的内存分配/释放（内存碎片化）等场景。
磁盘I/O压力：执行大量的文件写入和删除操作，旨在提高磁盘的吞吐量和IOPS，或测试磁盘的持续写入能力。

此外，它还能通过-i参数产生同步IO压力，主要调用sync()将内存缓冲区数据刷入磁盘，这会增加内核态CPU的消耗。

那么，哪些具体场景下你会需要它呢？我根据自己的经验罗列了几项：

容量规划验证：新采购了一台服务器，号称能支撑10000并发。你可以用stress搭配监控工具，看看在CPU、内存、IO均高负载的情况下，系统关键指标（如负载均衡、网络延迟）是否仍在健康范围内。
监控告警阈值校准：你的监控系统设置了CPU使用率超过80%就告警。这个阈值合理吗？用stress将CPU拉到95%运行一段时间，观察应用响应时间的变化，从而确定一个更科学、更贴近业务感受的告警线。
内核参数调优效果检验：调整了vm.swappiness（交换倾向）或磁盘调度算法后，系统在内存压力下的行为是否如预期改变？stress可以提供一个可重复的测试环境。
故障演练与应急预案：主动制造一次“可控的”磁盘写满或内存耗尽事故，看看你的应用日志、监控看板和应急响应流程是否都能正常工作。

2. 从安装到第一个压力测试：快速上手

虽然很多现代的Linux发行版（如Ubuntu、CentOS 8+）的仓库里已经包含了stress，但版本可能较旧。为了使用更稳定的特性，我们这里介绍从源码编译安装的方法，这也能让你更了解这个工具。

2.1 获取与编译安装

首先，我们需要下载源码包。你可以从官方的GNU镜像站或一些开源软件存档站点获取。这里以stress-1.0.4版本为例。

# 下载源码压缩包
wget https://fossies.org/linux/privat/old/stress-1.0.4.tar.gz

# 解压并进入目录
tar -xzvf stress-1.0.4.tar.gz
cd stress-1.0.4

# 配置、编译并安装
./configure
make
sudo make install

安装完成后，在终端输入stress --version，如果显示版本信息，则说明安装成功。

注意：在某些最小化安装的系统上，编译可能需要gcc和make等开发工具。如果./configure报错，请根据提示安装缺失的开发包，例如在Ubuntu上可以运行sudo apt install build-essential，在CentOS/RHEL上运行sudo yum groupinstall "Development Tools"。

2.2 你的第一个CPU压力测试

让我们从一个最简单的例子开始，直观感受一下stress的威力。假设我们想看看服务器在CPU满载情况下的表现。

# 产生4个持续进行数学计算的进程，运行30秒
stress -c 4 -t 30s

执行这条命令后，stress会启动4个“工人”，每个工人都会拼命地计算随机数的平方根（这是一个典型的CPU密集型操作）。-t 30s指定了整个测试持续30秒，时间一到，所有工人会自动停止，stress进程退出。

此时，立即打开另一个终端窗口，运行top或htop命令。你应该会看到有4个stress进程的CPU使用率接近100%（在top中，按1可以展开看到每个CPU核心的利用率）。同时，观察系统整体的负载平均值（load average），它应该会显著上升。

关键参数解析：

-c, --cpu N: 产生N个进行CPU压力测试的工人。通常，设置的数量不超过你服务器的逻辑CPU核心数（可通过nproc命令查看）。超过核心数会产生大量的进程上下文切换，测试场景会发生变化。
-t, --timeout N: 运行N秒后停止。时间单位非常灵活，支持s（秒）、m（分）、h（小时）、d（天）、y（年）。例如-t 5m表示运行5分钟。

这个简单的测试已经能告诉我们很多信息：CPU散热是否跟得上？服务器的功耗是否激增？在CPU满载时，其他低优先级的后台任务是否被严重饿死？这些都是评估系统稳定性的重要维度。

3. 深度参数解析与组合压力场景模拟

只会用-c和-t只是入门。stress的真正强大在于其丰富的参数，允许你精细控制压力的“质地”和“强度”。下面我们拆解几组核心参数，并看看如何组合它们来模拟真实世界中更复杂的混合负载。

3.1 内存压力测试：不止是占用

内存测试比单纯的CPU测试要微妙得多。stress的-m（或--vm）参数家族提供了多种内存行为模拟。

# 场景1：模拟持续占用1GB内存，持续60秒
stress -m 2 --vm-bytes 500M -t 60s

这条命令启动2个内存工人，每个工人分配并锁定500MB内存（共1GB），并在60秒内保持占用，然后释放。

但更贴近真实应用（如Java应用）的行为可能是频繁的分配与释放：

# 场景2：模拟频繁的内存分配/释放，容易引发内存碎片
stress -m 4 --vm-bytes 100M --vm-keep -t 120s

这里，--vm-keep参数是关键。它指示工人在每次malloc/free循环中，不是真正释放内存再重新分配，而是通过memset等方式“弄脏”已分配的内存块然后继续使用。这减少了向操作系统申请/归还内存的开销，让压力更集中在用户态的内存操作上，更能模拟某些缓存类应用的行为。

最“坏”的场景是模拟内存泄漏或内存耗尽：

# 场景3：分配大量内存并“挂起”，模拟内存不释放
stress -m 1 --vm-bytes 3G --vm-hang 0 -t 300s

--vm-hang N让工人在分配内存后，睡眠N秒再释放。当N为0时，表示永远睡眠（直到超时或被杀死），这意味着这3GB内存在测试期间被永久占用。这是一个非常危险的操作，请务必在测试机上谨慎使用，并明确设置超时时间-t。你可以通过这个测试，观察系统在物理内存被大量占用后，swap的使用情况、OOM Killer（内存溢出杀手）是否会被触发，以及触发后对系统其他进程的影响。

3.2 磁盘I/O压力测试：写入与清理

磁盘I/O测试通常是最影响系统整体稳定性的，因为它直接涉及持久化存储。stress的-d（或--hdd）参数用于产生磁盘写压力。

# 基础磁盘写入测试：创建1个工人，写入总计10GB的数据
stress -d 1 --hdd-bytes 10G -t 60s

这个命令会在当前工作目录下，创建一个临时文件，并持续向其中写入数据，直到写满10GB或60秒超时。默认情况下，stress会一边写一边删除（unlink）文件，所以你用df可能看不到磁盘空间持续减少，但iostat或iotop命令会显示持续的写入活动。

如果你想测试磁盘空间耗尽的影响，可以使用--hdd-noclean参数：

# 警告：此命令会填满当前磁盘分区！
stress -d 1 --hdd-bytes 50G --hdd-noclean -t 300s

--hdd-noclean阻止了文件删除，临时文件会一直保留在磁盘上。请确保你在一个独立的、空间充足的测试目录下运行此命令，或者使用-t设置一个较短的超时时间，避免生产环境磁盘被写满的灾难性后果。

3.3 组合拳：模拟混合型复杂负载

真实的服务器负载很少是单一的。一个Web应用服务器可能同时面临CPU计算（动态页面生成）、内存缓存（Redis/Memcached）和磁盘日志写入。stress可以轻松组合这些压力源。

# 模拟一个复合场景：高CPU、中等内存压力、持续磁盘日志写入
stress \
  -c 2 \               # 2个CPU工人，消耗约2个核心的计算能力
  -m 1 --vm-bytes 2G \ # 1个内存工人，占用2GB内存
  -d 1 --hdd-bytes 1G \ # 1个磁盘工人，持续写入1GB数据（循环覆盖）
  -t 10m               # 持续运行10分钟

执行这样的复合命令时，你需要同时监控多项指标。我建议使用像dstat或glances这样的综合监控工具，它们可以在一屏内显示CPU、内存、磁盘、网络等所有关键信息。

监控命令示例：

# 使用 dstat，每2秒刷新一次，查看综合资源使用情况
dstat -tcmnd --disk-util 2

# 使用 iotop 专注查看磁盘IO（需sudo）
sudo iotop -o -d 2

通过观察这些指标在混合压力下的互动关系，你可以发现一些单一压力测试无法暴露的问题。例如，当磁盘IO延迟极高时，CPU的iowait时间可能会飙升，即使你的应用本身不占CPU，整体响应也会变慢。

4. 结果解读、常见问题与高级技巧

运行了压力测试，看到了飙升的曲线，然后呢？解读数据比制造压力更重要。 这里有一些基于经验的分析角度和排错技巧。

4.1 关键指标解读与瓶颈识别

下表梳理了在不同压力类型下，你应该重点关注的系统指标及其含义：

压力类型	核心监控指标	健康状态解读	潜在问题信号
CPU压力	`%usr` (用户态), `%sys` (系统态), `%iowait`, Load Average	用户态CPU高是预期；系统态适中；iowait低。负载均值接近或略高于CPU核心数。	`%sys`异常高（可能系统调用频繁）；`%iowait`高（可能磁盘慢拖累CPU）；负载均值持续远高于核心数。
内存压力	`free`/`available`, `%mem`, `si`/`so` (swap in/out)	`available`内存减少；Swap有少量使用属正常。	`available`接近0；`si`/`so`持续高位（内存颠簸）；触发OOM Killer。
磁盘IO压力	`%util` (磁盘利用率), `await` (IO等待时间), `svctm` (服务时间)	`%util`高是预期；`await`和`svctm`应保持相对稳定在较低水平。	`%util`持续100%且`await`飙升（磁盘成绝对瓶颈）；`svctm`大幅增加（磁盘本身性能下降）。
混合压力	所有上述指标，以及网络、中断等	各项指标在各自合理范围内波动，无单项指标极端恶化。	出现连锁反应，如高IO导致高`iowait`，进而导致CPU负载虚高，应用排队。

4.2 实战中遇到的典型问题与排查思路

stress进程被系统“杀死”
- 现象：测试中途stress进程突然消失，系统负载下降。
- 排查：首先检查dmesg或/var/log/messages日志，看是否有Out of memory: Kill process记录。这很可能是OOM Killer出手了。解决方案：调整测试参数，减少--vm-bytes或-m的数量，或者为测试分配一个内存上限（如使用cgroups）。如果并非OOM，检查是否被用户手动kill或配置了资源限制（ulimit）。
测试达不到预期的资源占用率
- 现象：设置了-c 8，但top显示CPU总使用率只有400%（即4个核心满）。
- 排查：运行nproc确认逻辑CPU核心数。如果只有4核，那么-c 8会产生8个进程，但操作系统会在4个核心上调度它们，由于上下文切换开销，你看到的CPU利用率可能不会线性增长，且%sys可能会变高。建议：将工人数设置为等于或略高于CPU核心数进行测试。
磁盘测试对系统影响过大
- 现象：一运行-d测试，整个SSH连接都变得极其缓慢，甚至断开。
- 排查：这通常是因为测试目录所在的分区也是系统根分区或关键分区。大量的IO操作耗尽了磁盘的IOPS和带宽，导致系统连写日志、响应SSH都困难。最佳实践：永远在独立的、非关键的数据分区或磁盘上进行磁盘压力测试。可以使用df -h查看分区情况，并cd到目标目录（如/data/test）后再运行命令。

4.3 超越基础：让测试更贴近生产环境

使用taskset绑定CPU核心：如果你想观察特定CPU核心的行为，或者模拟NUMA架构下的内存访问延迟，可以使用taskset命令将stress进程绑定到特定CPU。
```
# 将stress绑定到0号和1号CPU核心上运行
taskset -c 0,1 stress -c 2 -t 30s
```
配合cgroups限制资源：在容器化环境中，或者想精确模拟一个拥有特定资源配额（如仅2核CPU、4GB内存）的“应用”，可以先用cgroups创建一个控制组，设置好CPU和内存限制，然后将stress进程放入该组进行测试。这能帮你验证应用的资源限制是否合理。
编写自动化测试脚本：将一系列不同强度、不同组合的stress命令，与监控命令（如vmstat 1 60）、结果收集命令（如将iostat输出重定向到文件）结合起来，写成一个Shell脚本。这样可以实现一键化的、可重复的压力测试流程，方便进行回归测试和对比测试。