简介：stress是Linux环境下常用的压力测试工具，通过消耗CPU、内存等系统资源模拟高负载场景，帮助开发者和系统管理员发现系统瓶颈与不稳定因素。提供的是stress-1.0.1完整源码包，面向需要开展系统稳定性评估、性能调优以及源码级研究的工程师和运维人员，尤其适合嵌入式与服务器环境。压缩包共32个文件，整体仅199KB，涵盖核心C源码、configure配置脚本、Makefile构建体系，以及texi和info格式的文档说明，轻量而完整。已有3089人学习下载。读者可获得一份结构清晰、可自由修改的源码工程，既能直接编译安装使用，也能深入理解stress实现CPU压力、内存压力及多线程负载的底层机制，按需修改或扩展功能；配合README、ChangeLog等材料，可快速掌握从构建到测试的关键步骤，是系统压力测试学习与二次开发的实用样例。
1. 先搞懂stress压的是什么：一个命令背后的三类压力源
在硬件验收和稳定性排查的场景里，很多工程师拿到新机器后的第一件事不是跑分，而是跑压力测试。常见的做法是：一台刚拆封的服务器，系统装好后先执行一条stress --cpu $(nproc) --timeout 600，然后盯着终端看十分钟，确认没有 panic、没有硬件错误，才敢把它放进生产环境。linux压力测试工具stress就是这样一个看着简单、但能把机器真实状态逼出来的工具。它通过生成CPU、内存、IO三类压力worker，让目标机器在满载甚至超载状态下暴露散热、供电、资源调度、OOM配置的问题。适合三类人：做容量评估的运维、验收新硬件的工程师，以及刚接触系统调优、需要一条可复现压测命令的开发者。
2. 三行命令跑通最小压测：安装、单核满载与组合负载
2.1 安装前的三个确认：权限、软件源与CPU拓扑
很多第一次用stress的人直接执行stress --cpu 4，然后发现命令不存在，卡在安装这一步。我一般会先做三个确认，避免后续折腾。
第一个是权限。stress需要向子进程发送信号并在超时后清理进程，所以至少需要普通用户能起进程，但压测结束后要让进程彻底退干净，最好有root或sudo权限。这不是绝对前提，但没权限时遇到残留进程会很难收场。
第二个是软件源。stress在多数发行版的基础仓库里，安装命令只有一行：
# apt系发行版 sudo apt install stress # yum/dnf系发行版 sudo yum install stress如果安装不上，优先检查软件源是否可用，而不是直接换工具。有些精简系统里没有现成包，也会用源码方式安装，但日常使用包管理器就够了。
第三个是CPU拓扑。压测前要知道机器有几个逻辑核、是物理核还是超线程，这决定你初始该压几个worker。常见做法是先看nproc和lscpu：
# 查看逻辑核数量 nproc # 查看架构与核数信息，确认是否超线程 lscpu | grep -E "^(CPU\(s\)|Model name|Architecture)"这一步的意义在于：不是每个worker都需要等于核数。worker数小于核数，测的是部分负载；等于核数，测的是满载；大于核数，测的是过载调度。先把CPU拓扑搞清楚，后面跑出来的数字才解释得通。
2.2 最小压测命令：先让一个核满载60秒
第1个建议尝试的最小命令是单worker短超时，用于确认工具本身工作正常：
# 只占满1个逻辑核，60秒后自动退出 stress --cpu 1 --timeout 60这个命令的逻辑：--cpu 1启动1个CPU worker，worker内部是一个不断做计算的循环，把所在逻辑核跑满；--timeout 60强制60秒后退出。之所以先跑单核，是为了把变量降到最少：如果单核跑60秒都没问题，再往上加worker，排查范围更小。
跑的同时另开一个终端观察：
# 每1秒刷新一次，看stress进程的CPU占用 top -d 1正常情况下top里能看到名为stress的进程，CPU占用接近100%，系统负载上升到1左右。这里有个经常让新人误判的现象：在4核机器上跑4个worker后，top第一行的CPU总和会显示接近400%，不是bug，是top把每个逻辑核的100%累加了。单worker显示100%只代表占满一个核，不代表机器已经满载。
2.3 组合压测：CPU、内存、IO同时上，顺便发现瓶颈
单核跑通后，就可以上组合负载。组合压测的目的不是追求某一个部件极限，而是模拟真实业务里“多个资源同时被抢”的状态。
下面这条命令是我平时做快速冒烟测试的起点：
# 4个CPU worker、2个内存worker（每个512MB）、2个IO worker，总共跑120秒 stress --cpu 4 --vm 2 --vm-bytes 512M --io 2 --timeout 120命令拆开看：--cpu 4起4个计算worker；--vm 2起2个内存worker，每个通过--vm-bytes 512M分配512MB内存并实际写入，两个worker合计占用1GB；--io 2起2个IO worker，它们反复调用sync()系统调用，主要压内核的syscall路径；--timeout 120是整个压测的总时长，到点后stress会给所有worker发信号并回收。
这条命令特别容易踩一个坑：如果机器的物理内存是16GB，你会看到free只降了1GB，内存几乎没有压力。原因后面专门讲，这里先记住一条原则：内存worker的数量和单worker分配量要按目标内存水位来算，而不是随手填。
另外，组合压测不要一上来就拉满。我见过有人直接在32核机器上跑stress --cpu 32 --vm 16 --timeout 3600，结果三条命令下去，机器立刻无响应，只能靠带外管理重启。稳妥做法是先小后大：先用短超时确认组合负载起得来，再逐步加时长和worker数。
3. 把参数当工况表用：CPU、内存、磁盘的压测组合模板
3.1 CPU压测参数：worker数、超时与负载分布的取舍
CPU压测的核心参数是--cpu和--timeout，但真正决定压测质量的，是你怎么选worker数。
worker数通常按“物理核数→逻辑核数→超过核数”三档来选。等于物理核数，测的是纯满载稳定性，比如散热和供电；等于逻辑核数，在启用超线程的机器上会多压一层超线程争抢；超过逻辑核数，则会引入调度器竞争、上下文切换和负载均衡问题，测的是系统在过载时是否还能保持可用。
我一般会用nproc作为满载基准，但不会直接拿它当最终值。如果目标只是验收CPU稳定性，先跑一小段：
# 先按逻辑核数满载跑5分钟，确认没有明显异常 stress --cpu $(nproc) --timeout 300如果机器有16个逻辑核，可以试着加4个worker变成20个，观察系统负载会不会失控。这里有个常见误用：以为worker数越多越能压出硬件问题。实际上worker数超过核数太多时，CPU时间大量消耗在调度和排队上，反而掩盖了计算单元本身的稳定性问题，结果更像是测调度器，而不是测硬件。
不要漏掉--timeout。我几乎不会跑没有超时的stress命令，理由很简单：压测一旦把系统负载拉满，ssh可能都连不上，没有超时兜底就只能去机房按电源。宁可多写一个--timeout，最多就是压测提前结束，不会造成失控。
--backoff参数也值得知道。它的作用是让各worker错开启动，避免所有worker在同一瞬间拉起造成初始负载尖峰。多worker压测时，这个尖峰经常被误读成硬件问题：
# 启动8个worker，每个worker延迟100毫秒后再进入循环 stress --cpu 8 --backoff 100000 --timeout 120--backoff的单位是微秒，100000就是100毫秒。这个参数在压测刚启动的十几秒内作用明显，能让CPU占用率曲线更平滑，读数更容易判读。
3.2 内存压测参数：--vm-bytes、--vm-hang 与 swap 边界
内存压测比CPU压测更容易翻车，因为stress的内存worker默认行为和你直觉里“占用内存”不一样。
先看默认值：--vm 1启动1个内存worker，它默认每次分配256MB，写入后立即释放，然后重复。这意味着如果不加参数，4个worker最多也就占用1GB内存，对一台32GB的机器来说几乎没有压力。
正确做法是先算目标内存水位，再反推参数。比如机器有16GB物理内存，想压到占用12GB，可以这样：
# 3个worker，每个分配4GB，分配后保持3分钟不释放 stress --vm 3 --vm-bytes 4G --vm-hang 180 --timeout 200这里3 × 4G = 12G，正好留出4GB给系统本身。--vm-hang 180表示每个worker在分配并touch内存后，保持180秒再释放，这模拟的是“内存被长期占用”的形态。不加--vm-hang时，内存会很快被释放，free里只出现一个短暂尖峰，很多人因此误以为stress不压内存。
还有两个参数要分清。--vm-stride控制touch内存时的步幅，默认是按页全部写入；如果设成--vm-stride 256，表示每隔256字节写一个字节，模拟稀疏访问模式，适合模拟某些应用对大块内存的离散访问。--vm-hang则控制保持时间，想触发swap时，把--vm-bytes加到接近物理内存总量，然后加长--vm-hang，观察swap的变化。
需要注意：内存压测不是越大越好。一旦分配总量超过物理内存且swap也不够，内核OOM Killer会介入并杀掉进程，压测结果会变成非零退出码。此时先看dmesg确认是不是OOM，而不是直接断定硬件有问题。
3.3 磁盘IO压测参数：-i与-d的区别、--hdd-bytes的陷阱
stress的IO参数有两个，很多人混着用，其实它们压的东西完全不同。
--io产生的是sync()系统调用压力。每个IO worker不停调用同步接口，主要压内核的syscall路径和调度器，并不会持续往磁盘写大量数据。想在ssd或机械盘上制造真实写入压力，靠--io是不够的，得用--hdd。
--hdd会创建临时文件并写入数据，写满指定大小后删除文件再重来，是真正能压磁盘写入路径的选项。常见做法是把它限定在临时目录里：
# 创建专门目录，避免临时文件散落在工作目录 mkdir -p /tmp/stress-hdd cd /tmp/stress-hdd # 2个磁盘worker，每个写512MB文件后删除重来，跑60秒 stress --hdd 2 --hdd-bytes 512M --timeout 60这里--hdd-bytes 512M限制每个worker每次写入的文件大小。如果不指定，stress默认按约1GB来写，临时目录空间不够时会把分区写满。--hdd的默认行为是在当前目录创建临时文件，所以一定要先确认当前目录在哪个分区、剩余空间多少。
还要说清楚边界：stress的磁盘压测是顺序写加删除，不是随机读写，也不是混合读写。想测磁盘的IOPS、时延、随机读写能力，需要换fio这类工具。stress适合做的是“长时间持续写盘能不能稳、文件系统会不会报错”这类稳定性验证。
3.4 三张场景模板表：验收新机器、稳定性回归、内存边界
把参数组合成模板，比每次临时拼命令更可靠。下面三张是我常用的起点模板，跑之前先估算资源和时长。
| 压测场景 | 推荐命令示例 | 关键观察点 |
|---|---|---|
| 新机器验收 | stress --cpu $(nproc) --vm 2 --vm-bytes 2G --timeout 3600 | 温度、负载是否稳定，有无MCE或panic |
| 稳定性回归 | stress --cpu 8 --io 4 --timeout 1800 | iowait是否过高，ssh是否保持不丢 |
| 内存边界探索 | stress --vm 4 --vm-bytes 4G --vm-hang 300 --timeout 360 | free是否降到目标水位，swap是否按预期参与 |
注意模板里的--timeout 3600是整整一小时。按下回车之前，先确认这段时长内没人需要这台机器干活，也确认压测期间发生问题时你有办法强制重启。模板只是起点，实际参数要按机器配置和业务容忍度来改。
4. 结果读数与判定：别让压测白跑
4.1 压测期间实时观测：top、vmstat、dmesg怎么配合
压测不是把命令跑起来就完事，读数是判断是否通过的关键。我一般开三个终端同时观测：
# 终端A：实时看CPU占用、负载和进程状态，每2秒刷新 top -d 2 # 终端B：每2秒输出一次系统状态，共60次 vmstat 2 60 # 终端C：实时看内核日志，OOM、panic、硬件错误第一时间出现 dmesg -wtop负责回答“CPU有没有跑满、负载是多少”。vmstat里更值得关注的是r列、si/so列和wa列：r列是运行队列长度，压测时接近worker数是正常，远超核数说明过载严重；si/so是swap换入换出，内存压测看这里最直观；wa是IO等待占比，如果长时间很高，配合--hdd看磁盘路径是否成了瓶颈。
dmesg -w 是很多人忽略的一环。压测过程中最怕的不是CPU满载，而是内核突然报panic、MCE硬件错误或hung task。这些信息在top里看不到，只有dmesg能及时暴露。
4.2 判定压测是否通过：退出码、panic与日志证据
压测是否通过，不是看“跑完没崩”这么简单。我的判断流程分三步。
第一步看退出码。stress正常跑完超时退出时返回0，非0说明压测过程有异常。但要注意，压测时系统变慢、负载变高都算预期，不代表失败；真正的失败是进程被异常杀掉、内核报错、主机无响应。
第二步查内核日志。压测结束后执行：
# 检查是否有内核级异常，输出时带上可读时间戳 dmesg -T | grep -iE "oom|panic|hung task|mce|hardware error"有输出不代表一定失败，比如OOM出现反而证明内存确实压到位了。但要区分清楚：OOM是策略生效，panic和MCE才是硬件或内核层面的硬故障。
第三步留证据。压测结果如果只靠肉眼记忆，很难和别人交代。至少把退出码、dmesg关键行、压测前后free和负载存下来。判定要看到日志再下结论。
有个容易把结果读歪的“玄学”点：同一台机器跑同样压测，第二次的结果和第一次有差异，不一定是机器不稳，可能是后台定时任务、温度降频或虚拟化邻居的干扰。要排除这些变量，就得压测前清场、压测中留痕、压测后多轮对比。
4.3 给压测留痕：一个简单的自动化记录脚本
手动开三个终端观测，适合临时验证；做正式验收时，我会用一个脚本把压测过程记录下来，跑完直接看文件。
#!/bin/bash # 压测留痕脚本：记录压测前状态、期间采样、退出码和压测后状态 LOG_DIR=/var/log/stress-report mkdir -p "$LOG_DIR" TS=$(date +%Y%m%d-%H%M%S) # 压测前的基线：内存量与CPU拓扑 free -h > "$LOG_DIR/before_$TS.txt" nproc >> "$LOG_DIR/before_$TS.txt" # 后台采集vmstat，每5秒一次，共120次，覆盖10分钟 vmstat 5 120 > "$LOG_DIR/vmstat_$TS.txt" & # 正式压测：按逻辑核数满载CPU，2个内存worker各2GB，跑10分钟 stress --cpu "$(nproc)" --vm 2 --vm-bytes 2G --timeout 600 RC=$? # 压测后的状态，以及退出码记录 free -h > "$LOG_DIR/after_$TS.txt" echo "stress exit code: $RC" >> "$LOG_DIR/result_$TS.txt"脚本的逻辑：压测前先记录基线和CPU拓扑，压测期间由后台vmstat持续采样，压测结束后记录最终状态和退出码。RC=$?是在stress命令结束后立刻捕获退出码，再写进结果文件。
这套留痕方式比肉眼看终端强在可回放：压测跑了多长时间、内存降到多少、退出码是多少，文件里都有。真出问题想回溯，也有数据支撑，不至于靠回忆判断。
5. stress实战避坑：五个翻车现场与对策
5.1 压测中机器卡死，ssh断连
现象：在16核机器上执行stress --cpu 24 --timeout 3600，几分钟后ssh连接中断，机器彻底无响应，只能靠带外管理重启。
原因：worker数超过逻辑核数太多，系统负载爆表，运行队列被填满，网络栈和ssh进程得不到调度，看起来像死机。再加上超时设成3600秒，中途无法收场。
解决：压测时始终带--timeout，哪怕只是熟悉环境也要带。worker数优先按nproc来，想测过载就从nproc + 2开始，而不是凭空拉高。另外可以用nice给压测进程降优先级：
# 降优先级运行stress，给系统管理留出调度余量 nice -n 19 stress --cpu 16 --timeout 300这样即使负载很高，ssh和systemd这些关键进程仍有机会被调度，机器不会“一次压死”。真要模拟极端过载，就别指望ssh还能连上，人得站在带外管理终端前再动手。
5.2 内存压测看不见效果，free只掉了一层皮
现象：执行stress --vm 4 --timeout 60，跑完后看free，内存只少了不到1GB，和预期严重不符。
原因：stress的每个内存worker默认只分配256MB，4个worker合计才1GB。加上没指定--vm-hang时，内存分配后很快释放，free里只短暂下降，跑完再看自然没有变化。
解决：先算目标内存量，再定worker数和单worker大小。例如16GB机器想压到12GB占用：
# 4个worker，每个3GB，分配后保持120秒，总超时150秒 stress --vm 4 --vm-bytes 3G --vm-hang 120 --timeout 150压测过程中用watch -n 1 free -h盯实时变化，不要压完才看结果。想压出swap，就把--vm-bytes总量提到接近物理内存，再给--vm-hang加长。
5.3 磁盘压测把分区写满，甚至留下大文件
现象：直接在/home或项目目录里执行stress --hdd 2 --timeout 300，几分钟后df -h显示分区使用率暴涨，压测结束后还有残留文件。
原因：--hdd会在当前目录创建临时文件并持续写入，每个worker每次写入约1GB大小。当前目录所在分区空间不足时，会被快速写满；如果是在重要目录里跑，还可能干扰正在使用的数据。
解决：压测前先建专用目录并切换过去，用--hdd-bytes限制单次写入大小，跑之前看一眼磁盘剩余空间：
# 先确认目录空间，再限定写入量 mkdir -p /tmp/stress-hdd && cd /tmp/stress-hdd df -h /tmp # 每个worker每次只写256MB，压60秒 stress --hdd 2 --hdd-bytes 256M --timeout 60压测结束后用ls -la确认目录无残留。这里有个血泪经验：长时间在SSD或U盘上反复跑--hdd，会明显加快写入寿命损耗，压磁盘前先想清楚这台机器的介质是不是消耗品。
5.4 内存压测时stress被Killed，误判系统不稳定
现象：执行stress --vm 8 --vm-bytes 4G --timeout 120，几秒后终端输出Killed，退出码非0，第一反应是硬件坏了。
原因：8个worker乘以4GB，总共需要32GB内存，超过物理内存后内核OOM Killer介入，主动杀掉stress进程来保护系统。这是内存策略在起作用，不是硬件故障。
解决：压测前先看内存总量和overcommit配置，把目标占用控制在物理内存的70%到80%左右。分层加压，先跑小内存量观察free曲线，再逐步增大--vm-bytes。被Killed后第一时间查证：
# 确认是否是OOM Killer干的，而不是硬件错误 dmesg -T | grep -i oom看到OOM记录，说明压测确实触达了内存边界，可以作为调参依据，不要急着换硬件。
5.5 同一条命令两次结果差异很大，复现不出来
现象：前一天跑stress --cpu 8 --timeout 600温度稳定，第二天同样命令跑10分钟就出现明显降频，负载曲线完全对不上。
原因：外部变量太多。常见的有：后台自动更新和agent定时任务抢CPU、物理机散热环境变化、虚拟化宿主机上其他邻居产生的CPU steal、系统负载残留。这些都是压测外的干扰源。
解决：压测前清场，停掉定时任务和更新服务；记录压测前的负载基线，用uptime和mpstat确认机器是空载的。虚拟化环境里重点看%steal：
# 查看是否有CPU被宿主机抢占，steal过高说明结果不可信 mpstat -P ALL 2%steal表示虚拟机等待宿主机调度的比例，如果持续超过5%，压测结果就不能完全代表这台机器的真实性能。正式验收建议同一场景跑三轮，取最差一轮当结论，不要被单次结果带着走。
6. 从stress到stress-ng：什么时候该升级压测方案
stress本身只有CPU、内存、IO、文件写入这四类压力源，粒度比较粗。它适合快速冒烟、单机验收、跑基础负载，但在更精细的场景里会显得不够用。比如你想压cache带宽、模拟大量socket连接、触发futex竞争，stress都做不到，这些正是stress-ng擅长的领域。
stress-ng的命令风格和stress很像，多数参数能直接迁移，但压力场景丰富得多。我的升级路径是：先用stress做一轮基础压测，确认没有低级问题，再用stress-ng做更细的策略轮换。比如下面的组合：
# 第一阶段：stress做30分钟基础满载验证 stress --cpu 8 --vm 2 --vm-bytes 2G --timeout 1800 # 第二阶段：stress-ng做更细的CPU方法轮换与内存访问模式压测 stress-ng --cpu 8 --cpu-method all --vm 2 --vm-bytes 2G --timeout 1800 --metricsstress-ng的参数解释：--cpu-method all会遍历全部CPU压力算法，不只是普通整数运算，能覆盖更多指令路径；--metrics在结束后输出详细的运行统计，比stress的退出码信息量更大。这个组合适合拿来验证“换了一版内核之后，机器长时间高负载会不会出问题”。
我的习惯是，任何生产级别的压测都会先stress冒烟，再stress-ng精压，而且每次必带--timeout和日志目录。不这么做的话，压测本身就可能变成事故的源头，机器没坏，先把人折腾坏了。希望帮到你。
本文还有配套的精品资源，点击获取
