Linux压力测试工具stress实战：从安装到拷机一条龙

简介：Linux压力测试工具stress 1.0.1源码资源包，面向系统管理员、运维工程师与嵌入式开发者，用于模拟CPU、内存、线程/进程等负载，评估系统在极限场景下的稳定性与性能表现。压缩包整体约199KB，共32个文件，以C源码、configure配置脚本、Makefile构建文件为主，兼有texinfo文档、man手册及ChangeLog等说明材料，目录沿用标准GNU工程结构，便于编译、安装与二次开发。该工具支持通过命令行灵活指定负载类型与线程数量，可模拟计算密集、内存紧张及高并发进程创建等场景。目前已有3031人学习下载，适合需要验证服务器承载力、排查资源瓶颈或开展性能调优的工程师。借助该包可收获完整源码与配套文档，既能直接用于压测环境搭建，也能深入研读stress的核心实现，为自行编写轻量级负载工具提供参考。

linux压力测试工具stress实战：从装库到拷机一条龙

做Linux运维和系统性能验证的朋友，一定绕不开一个场景：新买的服务器到了，要验证硬件稳不稳；内核打了一个补丁，要确认系统不会跑着跑着就崩；部署容器之前，要看看资源隔离到底靠不靠谱。这些场景都有一个共同的底子需求——给系统施加一个可控的压力，然后在压力下观察它的表现。stress就是干这个的，一个轻量、纯粹、用来给Linux系统制造负载的小工具，我用它做过不少次拷机和稳定性验证，这篇就来聊聊它的完整玩法。

1. 工具选型与核心概念

1.1 stress到底是个什么工具

stress是Amos Waterland写的一个C语言小工具，它的设计目标非常纯粹：通过fork出大量子进程，分别去消耗CPU、内存、磁盘I/O和资源分配能力，从而让系统进入一种可量化、可控的高负载状态。说人话就是——你告诉它“给我压出8个满负荷CPU的负载”，它就老老实实fork出8个进程，每个进程拼命算数学题，把CPU时间吃满。

很多人会把stress和stress-ng搞混。stress-ng是它的加强版，包含几百种压测方法，功能更强但复杂度也高。而stress的特点是参数简单、行为直观、结果容易判断，适合做快速验证和日常拷机。我个人的习惯是：快速验证用stress，深度专项压测用stress-ng或sysbench，但日常工作中stress出现的频率其实更高，因为它足够轻量，装完即用，不引入太多学习成本。

1.2 为什么需要给系统制造压力

很多人会有疑问：我的服务已经在线上跑了，为什么还要额外制造压力？这里有个概念要分清：线上跑业务是“实际负载”，压测工具制造的是“人工负载”。实际负载是随机的、起伏的、不好控制的，而人工负载是确定的、稳定的、可调节的。做稳定性验证时，你不希望负载忽高忽低导致结果无法解释，你希望CPU稳定在100%、内存稳定占用N个GB，然后观察系统在这种极端情况下是否还能正常工作。

stress的价值就在这里：它把负载变成了一个有刻度的仪器，让你能够在“系统扛不住之前”就掌握系统的边界在哪里。比如一台8核机器，先压6个CPU看看是否稳定，再压8个，再压10个（超卖），观察不同负载级别下的系统行为。这种测试在硬件验收、性能基线采集、容器限制验证中都属于必备环节。

1.3 适用场景梳理

从我实际接触过的使用场景来看，stress主要适合以下几种情况：

• 硬件拷机：新装机或购买二手服务器后，用CPU和内存压力验证硬件是否有隐性故障。
• 内核与驱动验证：打了补丁、升级了内核、更换了驱动，需要在负载下确认系统不会panic或死锁。
• 性能调优前后对比：调整内核参数、CPU调频策略之前和之后，用同样的压力对比系统表现。
• 容器与虚拟化资源限制验证：确认cgroup的CPU限制、内存限制是否真正生效。
• 教学和技术测试：演示系统负载、观察调度行为时，stress是干净利落的负载制造工具。

2. 安装部署与环境准备

2.1 各主流发行版的安装方法

stress的安装非常简单，官方源里基本都有现成的包。以最常见的几个发行版为例：

# Debian / Ubuntu sudo apt-get install stress # CentOS / RHEL 7/8/9 sudo yum install stress # Fedora sudo dnf install stress # Arch Linux sudo pacman -S stress

如果你用的是极其精简的发行版或者没有现成包，也可以从源码编译安装。stress的源码包很小，编译过程依赖也很少：

wget https://downloads.your.org/stress/stress-1.0.7.tar.gz tar -xzf stress-1.0.7.tar.gz cd stress-1.0.7 ./configure make sudo make install

安装完成之后验证一下是否成功：

stress --version

能输出版本号就说明OK了。我在编译安装时踩过一次坑：某些精简系统上缺少make和gcc，需要先用包管理器装好基础编译工具链再执行configure。

2.2 压测前的系统状态确认

在做压力测试之前，有一件小事经常被忽略：确认CPU调频策略。现在的CPU大多有自动调频功能，空闲时降频省电，负载高时自动升频。如果你不做任何设置，压测过程中CPU频率可能忽高忽低，测试结果的一致性会受影响。

建议在压测前把CPU调到最大频率或性能模式，观察一下当前频率运行状态：

# 查看当前CPU频率 cat /proc/cpuinfo | grep MHz # 使用cpupower工具设置性能模式（需要root权限） cpupower frequency-set -g performance

如果发行版没有cpupower命令，也可以装linux-cpupower（Debian/Ubuntu）或kernel-tools（CentOS）包。当然，如果你测试的目的恰恰是要验证调频策略本身的行为，那就不需要这一步，反而应该保持默认策略去压，具体取决于你的目标。

另外，压测前还要确认系统负载基线是干净的。最好在一台没有业务的机器上做压测，或者至少确认当前top显示的load average不高，避免把别人业务的负载误算进你的测试结果里。

3. 压测方案设计与核心参数

3.1 CPU压测：--cpu参数详解

stress最常见的用法是CPU压测，命令格式如下：

stress --cpu 8

这会在当前终端前台fork出8个子进程，每个进程执行一个计算平方根的死循环，把CPU核心吃满。根据我的实测，每个--cpu进程会跑在单核上，8个进程就能吃满8个逻辑核心。机器有多少核心可以用nproc查看。

这里有个决策点：如果机器是超线程架构，8核16线程，要压满所有逻辑核心应该用--cpu 16，还是只压8个物理核心？这取决于你的目的。如果你想验证整机散热和供电是否扛得住，那就压满16个线程，让所有逻辑处理器都进入高负载状态；如果你想模拟“每个物理核心承载一个典型业务进程”的场景，压8个可能更贴近实际。

CPU压测默认会一直跑下去，直到你按Ctrl+C终止。实际操作中通常需要限制时长，用--timeout参数：

# 压8个CPU核心，持续60秒后自动退出 stress --cpu 8 --timeout 60s

--timeout支持10s、1m、1h、1d这样的时间后缀，也支持纯数字（单位为秒）。加上超时控制的最大好处是不用干等，测试完自动退出，适合写进脚本里循环执行。

3.2 内存压测：--vm参数详解

内存压测用到--vm系列的参数：

# 启动4个内存压测进程，每个分配512MB内存 stress --vm 4 --vm-bytes 512M

每个--vm进程会调用malloc分配指定大小的内存，然后循环写入数据，确保内存页真实被触达。这里我补充一个容易被忽视的细节：malloc分配出来的内存在没有写入之前只是虚拟内存，不会占据实际的物理内存页。stress内部会通过写入操作对这些内存页进行实际触达，这也是它压内存比较有效的原因。

实际压测时，内存总量要算清楚。比如机器有8GB可用内存，你启动4个进程每个分配2GB，总量就是8GB。如果分配总量超过实际可用内存，系统会开始使用swap，性能会骤降；如果超过物理内存加swap的总量，则可能触发OOM Killer，某个进程被内核杀掉，测出来的结果就不具备参考意义。

还有--vm-hang参数值得说明。它会指示子进程在分配并写入内存后挂起一段时间，而不是反复随机读写。比如：

stress --vm 2 --vm-bytes 1G --vm-hang 30

两个进程各分配1GB内存并保持30秒不释放。这种模式适合测试“系统在内存长期以高占用率运行时是否稳定”，贴近数据库缓存、JVM堆内存这类常驻内存场景。

3.3 磁盘和I/O压测：--io与--hdd

磁盘I/O压测主要有两个参数：--io和--hdd。

# 启动4个I/O进程，每个进程不断执行sync系统调用 stress --io 4

--io的做法是不断fork新进程执行sync()，把文件系统缓冲区刷入磁盘，产生系统调用和I/O调度压力。不过说实话，这种压测方式对现代SSD来说压力并不大，它更多是压内核的I/O路径和调度器，不是直接压磁盘带宽。

想要更直接的磁盘写入压力，用--hdd：

# 启动2个写盘进程，每个向文件中写入1GB数据 stress --hdd 2 --hdd-bytes 1G

--hdd进程会创建一个临时文件（默认在/var/tmp目录下），然后反复写数据进去。这个测试会真实产生磁盘写入流量，可以用来验证磁盘的稳定性和散热。

这里有一个我踩过的坑：--hdd默认会在/var/tmp下生成临时文件，对于容量小的根分区，1GB甚至几GB的写入很容易把根分区磁盘占满。所以在跑--hdd之前，一定先看看磁盘剩余空间，同时建议用--hdd-bytes限制单次写入上限，或者指定文件路径。

3.4 组合压测：模拟真实混合负载

前面的参数都是单一维度的，但生产环境的负载从来不会只消耗一种资源。stress允许同时指定多个维度，一次压测模拟混合负载：

# 8个CPU进程 + 2个内存进程（各1G）+ 1个磁盘写入进程，持续5分钟 stress --cpu 8 --vm 2 --vm-bytes 1G --hdd 1 --hdd-bytes 1G --timeout 5m

这种组合压测更适合在真实服务器上做整体稳定性验证。比如你新部署了一个生产环境，想确认在“CPU高负载、内存大量占用、磁盘持续写入”的场景下，业务进程还能不能稳定响应，这种混合压测就很有参考价值。我在实际做服务器验收时，几乎都是用组合参数跑30分钟以上，而不仅仅是单测一个维度。

3.5 核心参数速查表

4. 实操过程与数据观察

4.1 一个完整的压测流程示例

在真正压测之前，我先做一次基线采集，也就是不做任何压测时记录系统初始状态。这一步很重要，因为后续判断异常都需要和基线对比：

uptime free -h df -hT /var/tmp mpstat -P ALL 1 3

假设我现在拿到一台8核16G的服务器，要做一次硬件稳定性验收，压测方案分三步走：

第一步，跑CPU压力10分钟，确认所有逻辑核心都稳定在100%负载：

stress --cpu 16 --timeout 10m

第二步，跑内存压力，按70%内存占用设计，16G机器留出系统余量，分配12G占用：

stress --vm 6 --vm-bytes 2G --timeout 10m

第三步，混合压测30分钟，模拟真实业务的高负载场景：

stress --cpu 16 --vm 4 --vm-bytes 2G --hdd 4 --hdd-bytes 2G --timeout 30m

三个步骤跑完，如果没有出现进程被kill、系统死机、内核报错等现象，基本可以认为这台机器的硬件和系统在合理的负载范围内是稳定的。

4.2 压测过程中的数据观察方法

压测启动后，记住一个原则：不要只盯着黑色终端等结果，要开另一个终端去观察系统状态。我最常用的观察工具组合如下：

• top/htop：看整体CPU使用率、load average、内存占用，判断压测进程是否达到预期负载。
• mpstat -P ALL 1：逐核查看CPU使用率。这个非常关键，能看出压力是否均匀分布在所有核心上，如果只有部分核心为100%，说明压测进程数量少了，或者存在中断绑核等问题。
• free -h：查看内存与swap使用情况。如果内存压测导致swap开始大量增长，说明压测内存分配过量，不是理想状态。
• iostat -x 1：观察磁盘使用率、吞吐量和I/O等待时间，配合--hdd压测使用。

这里我举个例子。用stress --cpu 8压一台8核机器，在另一个终端跑mpstat -P ALL 1，正常情况下每个CPU的%usr都接近100%。但如果发现其中某个CPU的%usr只有50%左右，可能就是stress进程被调度到了中断处理较多的CPU上，或者系统本身有绑核配置。这种细节在高精度压测中值得排查。

4.3 压测时的安全注意事项

压测说到底是在挑战系统的极限，所以要讲究分寸。几个我吃过亏的教训分享给你：

第一，不要在远程连接的唯一会话里直接跑大压力测试。如果你用的是SSH连服务器跑压力测试，压力过大可能导致系统响应变慢甚至假死，你的SSH连接有可能断掉，然后你就失去了对机器的控制。建议用tmux或screen起一个会话跑压测，即使连接断了，压测进程还能继续运行，重新连上后还能看到之前的输出。

第二，内存压测总量一定要留余量。别把物理内存压到100%，给系统内核和基础服务留出几百MB甚至更多的余量，否则OOM Killer启动后，可能把不该杀的系统服务给杀了，测试结果会被严重污染。

第三，跑磁盘压测前确认磁盘空间和磨损程度。如果是机械硬盘或老旧SSD的机器，长时间--hdd压测会加剧磁盘磨损。这种测试不是不能做，但要有目的性，不是为了测磁盘本身就没必要长时间跑。

5. 常见问题与排查技巧实录

5.1 压测以后系统负载降不下来

这个问题我遇到不只一次。明明按了Ctrl+C或者--timeout到了时间，系统负载依然很高。排查步骤是这样的：

先用top看是哪个进程在消耗CPU，如果是stress的残留子进程，用pkill -f stress清理。注意stress的父进程退出后，某些子进程可能会变成孤儿进程继续运行。这时可以：

pgrep -l stress

列出所有名字包含stress的进程，逐个确认后清理：

pkill -9 stress

另外，如果CPU压测跑完LOAD值依然很高，但CPU使用率已经降下来了，那可能是系统在刷脏页或等待I/O完成，这时候耐心等一下就好，通常不会持续太久。

5.2 内存压测触发OOM Killer

内存压测时系统报错Out of memory: Kill process说明压测配置和机器实际内存不匹配。比如一台只有4G内存的机器，你直接跑stress --vm 8 --vm-bytes 1G，8个进程共需要8G内存，远超物理内存，OOM Killer就会出手。

解决方案是精确计算内存分配量。建议先看free -h确定可用内存，最多用70%到80%的可用内存做压测。假设机器有8G内存，系统已用2G，可用约6G，那压测内存量控制在4G到5G比较合适，可以配置成：

stress --vm 4 --vm-bytes 1G

还有一种情况：你确实想压到OOM，看系统能不能正确杀掉内存超限进程从而保护主机不挂，这种测试在容器环境验证时其实是有效的验证手段。但如果你的目标是验证“系统在内存高负载下稳定运行”，那就要避开OOM阈值。

5.3 --hdd压测后临时文件没清理干净

stress --hdd跑完后会在/var/tmp下留下临时文件，按我的经验它会以类似stress.XXXXXX的命名方式写入文件。如果不清理，日积月累会占用不少磁盘空间。清理命令很简单：

ls /var/tmp/ rm -f /var/tmp/stress.*

为了避免这个问题，更推荐的做法是在命令里就指定临时文件路径，放到专门的测试目录下，测完直接删目录：

mkdir /tmp/stress-test stress --hdd 2 --hdd-bytes 1G --timeout 1m

跑完以后删除整个测试目录，干净利落。

5.4 压测过程中SSH超时断连

这是一个很实际的运维场景：你通过SSH连接服务器跑长时间压测，压测到一半SSH连接断了。排查思路是：先确认是不是网络侧的会话超时限制，同时建议所有长时间压测都放进tmux会话中执行。我已经养成习惯，凡是超过10分钟的压测，一律先建tmux会话：

tmux new -s stress-test stress --cpu 16 --timeout 1h # 按 Ctrl+B 再按 D 脱离会话，连接断了也不影响压测进程

重新连接后用tmux attach -t stress-test回到压测会话，查看输出情况。这个习惯帮我避免了多次远程压测断连后无法确认结果的麻烦。

5.5 压测结果如何判断是否成功

最后聊一下怎么判断压测结果。stress本身不会输出一个“通过/失败”的结论，你需要自己综合判断。我个人的判断标准有三条：

1. 压测期间系统没有出现严重错误日志（dmesg中没有OOM、panic、硬件报错）。
2. 压测结束后SSH和基础服务依然正常响应，负载能回落到正常水平。
3. 压测期间业务进程（如果有）没有出现崩溃或者长时间无响应。

这三条都满足，这台机器基本可以认定在当前压测配置下是稳定的。如果再严格一点，可以对比压测前后/proc/cpuinfo和smartctl的磁盘健康状态，确认没有新增的硬件隐性故障。

结尾

我在实际使用stress过程中最大的体会是：工具本身简单到不行，真正的复杂度在于你怎么设计压测方案和解读压测结果。压测之前先想清楚要验证什么，再动手跑，数据才有参考价值。最后分享一个小技巧：如果你需要定期做压力测试，可以写一个脚本把stress和stress-ng配合使用，先用stress做快速冒烟验证，确认基本功能正常后再用stress-ng做专项深度压测，这样兼顾了效率与深度，我在多个项目的服务器验收中都是这么做的，效果一直不错。

本文还有配套的精品资源，点击获取