简介：这是一份面向Linux系统管理员、运维工程师与初学者的系统压力测试工具资源，核心是stress命令，通过构造CPU计算与内存读写负载，模拟高并发场景，验证服务器稳定性与极限性能。资源包采用源码发行版组织形式，共32个文件，压缩后仅199KB，包含configure配置脚本、Makefile.in编译模板、stress.c核心实现、texinfo技术文档及info/HTML阅读版本，并附有AUTHORS、ChangeLog、README等规范归档，便于学习源码结构、自行编译安装或二次开发。压力参数调节、线程数量设置、运行时长控制、与top/vmstat等监控工具联动等知识，均可从包内技术文档和源码注释中系统梳理。这些文件相互配合，构成完整的开源工具项目，适合作为学习系统编程与测试工具开发的样本。包体轻量、目录典型，对理解Linux工具链构建流程也有直接帮助。目前已有1034人学习下载，适合需要评估高负载表现、排查性能隐患或研究压力测试原理的工程师与学习者。 我们做运维和服务器调优的，最怕听到的一句话就是“业务上线当天突然卡死”。这种事儿我经历过不止一次，后来学乖了：新机器到手、大版本升级完、架构调完，别急着直接切流量，先拿压力测试工具把机器“蹂躏”一遍，看看它在极限状态下会不会原形毕露。市面上这类工具不少，但要说最轻量、最普及、同时也是最不容易出幺蛾子的，还得是stress，也就是大家常说的“linux加压测试工具”。
这篇东西不只是给你罗列命令参数。我会从实际运维视角出发，讲清楚怎么用 stress 把一个四核八线程的服务器压到指定负载，怎么用配套的监控命令同时盯住 CPU、内存还有 GPU 状态，以及在压测过程里你十有八九会踩到的坑和应对办法。无论你是刚接触 Linux 服务器的学生、准备面试的运维新人，还是正在做硬件验收的嵌入式工程师，这篇文章应该都能帮你省下不少自己摸索的时间。
1. 先搞明白：用 stress 到底在测什么
很多人对压力测试有个误解，觉得就是“把 CPU 跑满看看死不死机”。这话对了一半，但不全对。一台服务器的稳定性，是由 CPU、内存、IO 子系统、散热、供电等多个环节共同决定的，只看 CPU 满载远远不够。这也是我把 stress 作为首选工具的原因——它虽然命令短小，但覆盖面其实挺广。
1.1 压力测试解决的痛点
我们做压测，本质上是在回答三个问题：这台机器在持续高负载下会不会崩溃？它能不能在规定时间内完成计算任务？以及，它在高负载时的资源分配是否公平合理？
举个例子，去年我们部门采购了一批新服务器，配置看着都挺高，双路 CPU、512GB 内存。结果用 stress 压了一晚上，发现其中一台只要 CPU 负载超过 80%，内存延迟就飙得离谱，最后定位是 BIOS 里 NUMA 设置有问题。这种问题，你要是只跑个业务测试，短期内根本发现不了；但用 stress 做持续压力灌注，几分钟就能暴露出来。
另一个常见场景是散热和供电验证。机房夏天高温时段，空调一故障，满负载运行服务器的故障率会急剧上升。我们会在交付前先用 stress 把机器加热半小时，再配合传感器看温度曲线，相当于提前给机器做一次“体能测试”，比等它宕在线上再救火强太多了。
1.2 stress 和 stress-ng 怎么选
说实话，stress这个经典工具有点年头了，它的功能相比后来出现的stress-ng显得朴实很多。stress-ng是它的增强版，支持几百种压测方式，甚至可以指定让 CPU 执行特定的整数或浮点运算指令来做定向验证。
我的建议是：日常快速验证、教学演示、CI 流水线里做冒烟测试，用stress就够了。它简单靠谱，几乎不会出现工具自身崩溃的问题。但如果你要做深度的内核调度验证、大规模故障注入模拟，或者需要同时压测网络栈和进程数，那直接上stress-ng更合适。这两者的命令参数风格很接近，学会了stress再切过去，成本很低。
注意：stress 本身的定位是“制造可控负载”，不是 benchmark 工具，它不会告诉你“这机器性能分数是几分”。性能跑分请找 sysbench、unixbench 或者 phoronix test suite，别拿它干不属于它的活儿。
2. 环境准备与安装部署
stress 的安装方式与 Linux 发行版相关，但整体无脑简单，因为主流的软件源里都收录了它。
2.1 不同发行版的安装方法
Debian/Ubuntu 系，也就是你搜到的“ubuntu stress 测试”相关的场景，用 apt 一行搞定：
sudo apt update sudo apt install -y stressCentOS/Rocky/RHEL 系用 yum 或 dnf：
sudo yum install -y stress # 或者 sudo dnf install -y stress如果是国产 Linux 发行版，比如麒麟、统信 UOS，它们大多基于 Debian 或 CentOS 改造，先看 /etc/os-release 确认底子，再套用对应的命令就行。如果你是完全离线环境，比如一些内网服务器，那就去官网下源码包手动编译安装，三分钟也能搞定：
tar -xzf stress-1.0.7.tar.gz cd stress-1.0.7 ./configure make sudo make install编译期间如果提示缺 gcc，先apt install build-essential补上基础编译环境。
2.2 验证安装与查看可用参数
装完先别急着压，运行下面两条命令确认安装结果和帮助信息：
stress --version stress --help如果版本号能正常打印，说明安装成功。--help输出里会列出所有可用参数，后面我会一个个拆开讲。新手第一次看这个帮助文档可能会晕，因为里面的描述比较精简，但配合我这篇文章的解析，你能很快理解每个参数的适用场景。
3. 核心参数详解与实战命令
这一部分是整篇文章的重头戏。stress 的所有操作都围绕参数展开，理解了参数，你就等于掌握了这把“液压机”的控制面板。
3.1 CPU 压力测试：让每一个逻辑核心都转起来
CPU 压测是所有压测动作里最常用的。命令格式是：
stress --cpu N其中 N 表示生成 N 个 worker 进程，每个 worker 会不断地计算平方根。如果你想把 4 核 8 线程的机器全部压满，N设置成 8 即可，因为 Linux 会把这些 worker 尽量调度到不同的逻辑 CPU 上：
stress --cpu 8 --timeout 60上面的命令会持续压测 60 秒后自动退出，你不用手动去 kill 进程，非常省心。
如果你只是想看机器在 50% 负载下的表现，比如做数据库性能对比测试时想控制变量，那就把 N 设置成核心数的一半。四核机器压两个 worker，负载大体就是 50%。这个“大体”取决于调度器，但实测八九不离十。
3.2 内存压力测试：榨干内存带宽与容量
内存压测用--vm参数，它的坑更多，也更需要谨慎操作：
stress --vm 2 --vm-bytes 1G --timeout 30这条命令会让 2 个 worker 进程，各自分配并持续读写 1G 的内存，总消耗量约为 2G。--vm-bytes不写的话，默认是 256MB，在实际测试里这个量级往往不够，建议根据需求显式指定。
这里有个非常重要的实战提示：不要盲目分配超过物理内存容量的数值。比如你的服务器总内存只有 4G，却写了--vm-bytes 8G，系统会开始动用 swap 分区，压测效果会打折，极端情况下还会触发 OOM Killer 把进程杀掉。这种行为在测试环境里还没什么，在生产环境可能误杀业务进程，千万注意。
我的习惯是先将内存总量乘以 0.8 作为上限，再按 worker 数量做除法。举个例子，16G 内存的机器，我打算开 4 个 vm worker，那么每个 worker 的--vm-bytes就设为3G，确保最大消耗量约 12G，既能把内存压力抬起来，又留出了系统运行的基本余量。
3.3 IO 与磁盘压力测试：模拟磁盘繁忙场景
IO 压测有两种，一种是模拟磁盘写压力，另一种是模拟磁盘读写同步压力。
单纯让磁盘忙碌用--hdd，用法如下：
stress --hdd 4 --hdd-bytes 2G --timeout 60这条命令会生成 4 个 worker，每个 worker 不断地通过write系统调用写数据、再unlink删除，持续时间 60 秒。--hdd-bytes指定了每个 worker 写多少数据后执行删除操作，数值设大一点可以减少频繁删除文件带来的额外干扰，让压力更集中。
另一种是--io，它会让 worker 进程不断调用sync()系统调用，把文件系统缓存强制落盘。有人喜欢拿它模拟“大量小文件同步”的场景，但我实际用下来发现它对系统整体负载的提升不如--hdd明显，而且在某些 SSD 上会因为瞬时 IO 队列过长，间接拖垮同一台机器上的其他应用。所以我现在一般只在测试文件系统的同步行为时才用它：
stress --io 4 --timeout 30如果你是要模拟高 IO 等待的场景，比如数据库频繁 fsync，--io配合--hdd一起使用会更有针对性：
stress --io 2 --hdd 2 --timeout 603.4 多维度混合压测与参数计算
生产环境里很少有只消耗单一资源的现象，线上业务往往是 CPU、内存、磁盘同时忙。所以最后的验收压测，我通常会把几类负载揉在一起，模拟真实的高强度混合负载。
比如一台 8 核 16G 的 Web 服务器，我可能会这样操作：
stress --cpu 8 --vm 2 --vm-bytes 4G --hdd 2 --hdd-bytes 4G --timeout 600这里的参数组合逻辑是：8 个 CPU worker 占用全部逻辑核；2 个内存 worker 各自消耗 4G，合计 8G 内存，占总量一半；2 个磁盘 worker 持续写临时文件，再删除，模拟业务日志产生和归档的行为。总共压 10 分钟，留给监控系统足够长的观察窗口。
这里有个参数搭配的小技巧：--timeout尽量设置在压测命令的最后面，同时加上--verbose标志，这样当压测结束时，你能清楚看到每个 worker 的退出状态：
stress --cpu 8 --vm 2 --vm-bytes 4G --timeout 600 --verbose4. 压测时的实时监控体系：CPU、GPU、内存状态全都要看到
压测本身只是手段，监控才是发现问题的关键。很多人压测失败，不是命令没用对，而是压测跑起来之后，只盯着终端里一段干巴巴的输出，完全不知道机器内部发生了什么。这一节我重点讲怎么“边压边看”，这也是你搜“需要看到 cpu gpu 各种状态”时最关心的问题。
4.1 CPU 与内存监控：从 top 到 mpstat
最基础、最通用的命令是top，压测跑起来后，输入top，按数字键1，就能看到每个逻辑核心的实时使用率。如果所有核心都接近 100%，说明你确实把 CPU 压满了。
top有一点让我不太满意：它的历史趋势不够直观，你想回看 10 秒前的负载状态比较麻烦。所以现场环境里我更喜欢用htop（如果没装，apt install htop即可），它能用不同颜色实时展示每个核心的使用率条形图，一眼就能看出负载是否分布均匀。如果某些核已经红色爆表，另外几个核还蓝着，多半是 IRQ 绑核或者进程没绑定核心，这时候再去深挖 smp_affinity 设置，效率会高很多。
想看更详细的核心使用率统计，mpstat比top更专业：
mpstat -P ALL 1-P ALL表示统计每个逻辑核心，数字 1 表示每秒钟刷新一次。它会列出%usr、%sys、%iowait、%idle等指标，比 top 输出的一堆数据更容易定位问题到底出在用户态还是内核态。
4.2 GPU 状态监控：服务器带 GPU 时的强制要求
网上搜“stress linux加压测试工具”时，很多人会顺带问 GPU 怎么测、怎么看。这里澄清一个关键点：stress 默认不压 GPU，它的压测对象是 CPU、内存和磁盘。如果你是做 AI 训练、深度学习推理这类 GPU 相关工作的，压测时需要两个步骤配合。
第一步，用 GPU 计算负载工具去压 GPU。社区里常见的方案是gpu-burn，也有直接用pytorch执行矩阵乘法的。我个人觉得gpu-burn更纯粹些，它在 GitHub 上开源，编译后跑几分钟就能看到 GPU 负载拉满。
第二步，用监控命令观察 GPU 状态。NVIDIA 卡用官方自带的nvidia-smi：
nvidia-smi -l 1-l 1表示每秒钟刷新一次。输出里你能看到 GPU 利用率、显存占用、温度、功耗等关键数据。压测时 GPU 利用率在 95% 以上、温度缓慢上升并最终稳定、功耗接近设计最大值，这些都是正常现象。如果利用率始终上不去，那就要想想是不是 CPU 成为瓶颈了，数据集加载太慢导致 GPU 在空等。
如果是国产 GPU，比如华为昇腾、寒武纪、摩尔线程等，它们通常自带类似npu-smi的配套工具，思路和nvidia-smi一样，大同小异。
4.3 一键组合监控方案：用 watch 把多个维度拼在一屏
压测时最理想的状态是：一个终端窗口里，同时能看到 CPU、内存、负载均值、磁盘 IO、GPU 状态。一个窗口切换来看确实麻烦，尤其是在现场做巡检时。
我现在的习惯是用watch命令把多个监控工具的输出整合在一起。一个组合例子是这样的，先用 Ctrl-C 结束正在跑的单个监控命令，然后：
watch -n 1 'echo "===== CPU & MEM ====="; mpstat -P ALL 1 1; echo "===== LOAD AVG ====="; uptime; echo "===== GPU ====="; nvidia-smi --query-gpu=utilization.gpu,memory.used,temperature.gpu --format=csv'这段命令每 1 秒刷新一次，把 CPU 核心使用率、平均负载、GPU 利用率和温度都打在同一个屏幕上。虽然格式粗犷了一些，但现场排查问题效率极高，你不用来回切换终端窗口。--query-gpu那一段是 NVIDIA 卡的写法，它比默认的nvidia-smi输出更精简，适合屏幕空间有限时使用。
如果你的机器没有mpstat，装sysstat包就能获得它：
sudo apt install -y sysstat5. 常见问题与排查技巧实录
最后这部分，我把自己这几年来用 stress 踩过的坑、被同事问过的问题整理成速查表。每一行都来自真实场景，不是网上随便抄来的。
| 问题现象 | 可能原因 | 解决办法 |
|---|---|---|
| 压测命令执行后几秒就退出，没有任何报错 | --timeout参数单位写错，误写为分钟概念 | --timeout的单位是秒，想压 10 分钟就写600，不是10 |
| 压测时内存消耗远超预期，系统卡死 | --vm与--vm-bytes组合后的总消耗超过物理内存 | 先算出总量，控制在物理内存的 80% 以内 |
| 压测结束后，负载仍然很高 | 压测产生的临时文件没有清理干净 | 用--hdd压测后，检查/tmp或当前目录下的 stress 临时文件，手动删除 |
使用--hdd压测时，提示磁盘空间不足 | 没有指定--hdd-bytes，默认写的临时文件过大 | 加上--hdd-bytes，设置为小于磁盘剩余空间的值 |
| 远程 SSH 压测时，中途断连导致压测进程被杀 | SSH 会话结束时，终端进程收到 SIGHUP 信号 | 切换用 tmux/screen 或在命令前加 nohup |
| 压测时 GPU 利用率始终为 0 | stress 本身不压 GPU，只压了 CPU 内存 | 改用 gpu-burn 或深度学习负载来压 GPU |
| 多核机器压测不均匀，部分核心打满，部分核心闲置 | BIOS 里可能开了节能模式，或系统有中断绑核 | 检查cpupower frequency-info，必要时把 CPU 调为 performance 模式 |
这里挑几个重点展开讲一下，都是容易踩的坑。
5.1 远程压测一定要挂后台
有一次我在机房远程压测一台新到的机器，压到一半，人出去接了个电话，回来发现 SSH 断开了，连上去一看压测进程已经没了。后来我才意识到，SSH 断开时系统会给当前终端相关的进程发送挂断信号（SIGHUP），导致 stress 随之退出。
解决办法很简单，用nohup或者tmux。我个人更推荐tmux，因为它不仅能防止断连，还能让你随时重新接管会话查看压测结果。做法是先开一个 tmux 会话再执行压测命令，就算 SSH 断开，重连后tmux attach就能回来。
5.2 压测时留意系统日志
压测不只是报“死机”“没死机”这两个结果，很多硬件隐患是在压测过程中通过系统日志暴露的。压测期间，建议另开一个窗口用dmesg -w实时观察内核日志。如果出现大量 ECC 内存报错、PCIe 链路降速、磁盘 IO 超时之类的记录，那这台机器即使没宕机，也不能直接上生产，需要进一步排查硬件。
5.3 压测后必做的三件事
很多新手压完机器，看着终端没有报错就完事大吉了。我每次压完一定会做三件收尾工作：
第一，确认 stress 进程真的退出了。如果当时用了--timeout，理论上它会自动退出，但你最好还是用pgrep -a stress检查一遍，防止个别 worker 卡死残留。
第二，看系统平均负载是否回落。运行uptime，如果负载在压测结束后很久仍然处于高位，说明可能有进程卡在不可中断的 D 状态，需要进一步排查。
第三，检查压测期间是否生成大量临时文件。find /tmp -name 'stress*'扫一下，别让测试产生的垃圾占用生产磁盘空间。
写在最后的建议
如果你问我，压测这件事里最重要的一个字是什么，我会说是“耐心”。stress 这类工具很简单，翻来覆去就那几个参数，但它逼着你去长时间盯着机器、去理解监控数据背后的含义、去把 CPU 和内存和 IO 当作一个整体来审视。这个过程没法省，也不应该省。
我个人的做法是：测试环境里把 stress 跑成常态化动作，每次上线前做一次 10 分钟混合压测；新硬件验收时跑一整晚的极限压测，然后导出监控数据归档留底。这样等机器真正上了生产，我手里有它的完整“体能报告”，面对业务高峰时心里就不慌。
最后再分享一个小技巧：如果某天你拿到一台新的 Linux 服务器，不知道它的真实性能底线，先跑一行stress --cpu $(nproc) --vm 2 --vm-bytes $(free -b | awk '/Mem:/{print int($2*0.4)}') --hdd 4 --timeout 300，这行命令会自动按当前机器的 CPU 核数和内存大小生成压测负载。虽然看起来很“程序员偷懒”，但实际效果很稳，推荐你也试试。
本文还有配套的精品资源，点击获取
