简介stress 是 Linux 平台上一款经典的开源系统压力测试工具面向系统管理员、运维工程师与内核调优爱好者用于在受控环境下模拟 CPU、内存、进程与线程的高负载场景评估系统极限性能与稳定性。本资源为 stress-1.0.1 源码包共 32 个文件压缩后约 199KB包含 configure 构建脚本、stress.c 核心源码、Makefile 系列编译文件、README/INSTALL 说明文档以及 texinfo 手册与 man 帮助页等覆盖从编译安装到参数查阅的完整链路。源码结构清晰便于读者理解压力测试的线程调度与资源占用实现原理也可按需修改参数定制测试强度。目前已有 3079 人学习下载适合希望深入掌握 Linux 性能测试与稳定性验证的读者参考实践。1. 别等线上雪崩才想起它stress 到底压的是什么凌晨两点被告警叫醒登录一台 4 核 8G 的机器load average已经飙到 40业务进程被 OOM Killer 干掉两个。排查半天发现不是代码问题是有人在这台机器上跑了个定时任务把 CPU 和内存同时吃满。事后复盘时我一直在想如果上线前就用 linux 压力测试工具 stress 把资源边界摸一遍这场事故根本不会发生。stress 是 Linux 下最轻量的系统级压力测试工具它不测业务接口也不测数据库 QPS它压的是操作系统本身——CPU、内存、磁盘 I/O、进程创建。你给它一个核数、一个内存大小、一个超时时间它就用最粗暴的方式把这些资源占住然后你观察系统在高负载下的表现调度是否正常、OOM 会不会误杀、监控能不能及时报警。它适合运维做容量验证、适合开发做资源泄漏复现、也适合新手拿来理解 Linux 的负载到底长什么样。这篇文章不讲教科书定义只讲我实际怎么用它、参数怎么调、哪些坑踩过之后再也不碰。2. stress 的安装与最小可用命令先把第一把火点起来2.1 三种安装方式与选型理由stress 本身是个非常小的 C 程序源码只有几个文件编译出来不到 100KB。安装方式主要有三种选哪种取决于你的环境和权限。第一种是包管理器直接装Debian/Ubuntu 系用aptRHEL/CentOS 系用yum或dnf。这是最省事的方式但要注意发行版仓库里的版本可能偏老功能上一般够用。# Debian / Ubuntu sudo apt update sudo apt install -y stress # RHEL / CentOS / Fedora sudo yum install -y stress # 或者 sudo dnf install -y stress第二种是源码编译适合仓库里没有包或者你需要特定版本的情况。stress 依赖gcc和make有些精简镜像里这两个都没有得先补上。# 安装编译依赖 sudo apt install -y gcc make # 下载源码以官方 tar 包为例具体地址以实际可获取的为准 tar -xzf stress-1.0.4.tar.gz cd stress-1.0.4 ./configure make sudo make install第三种是容器里直接用很多基础镜像不带 stress可以在 Dockerfile 里加一行RUN apt install -y stress或者用带 stress 的镜像做临时压测容器。容器里跑 stress 要注意一点容器看到的 CPU 和内存是 cgroup 限制后的压出来的效果和宿主机直接跑不一样后面避坑章节会细说。提示生产环境装 stress 之前先确认变更窗口这东西跑起来是真的能把机器打挂别在业务高峰期手抖。2.2 最小可用命令4 核 CPU 压 60 秒装完之后先跑一个最小命令确认工具能用也顺便看看系统在压力下的基本反应。# 启动 4 个 CPU 压力进程持续 60 秒结束后自动退出 stress --cpu 4 --timeout 60s这条命令的含义拆开看--cpu 4表示 fork 出 4 个 worker 进程每个进程跑一个死循环做浮点运算把 CPU 占满--timeout 60s表示 60 秒后所有 worker 自动退出不需要你手动 kill。执行期间另开一个终端跑top或htop能看到 4 个stress进程的 CPU 占用率接近 100%。参数说明--cpu N里的 N 不一定要等于核数你可以给 8 去压一个 4 核机器这时候 load average 会超过核数能观察到调度器在超载情况下的行为。--timeout支持s、m、h、d单位写60不带单位默认是秒。如果不加--timeoutstress 会一直跑到你手动CtrlC或者kill这在脚本里用很危险建议永远带上超时。2.3 内存与 I/O 的最小验证CPU 压完再试内存和磁盘这两项出问题的概率比 CPU 高得多。# 启动 2 个内存压力进程每个分配 256MB 并持续读写压 30 秒 stress --vm 2 --vm-bytes 256M --timeout 30s # 启动 1 个 I/O 压力进程用 sync() 刷 4 次压 30 秒 stress --io 1 --hdd 1 --hdd-bytes 512M --timeout 30s--vm 2是 fork 两个内存 worker每个 worker 默认会malloc256MB 然后不断写入再释放模拟内存抖动。--vm-bytes 256M改的是每个 worker 分配的大小注意是每个 worker 而不是总量写--vm 4 --vm-bytes 1G就是 4 个进程各 1G总共 4G别算错了把机器直接打 OOM。--io 1是 fork 一个进程反复调用sync()把页缓存刷到磁盘--hdd 1是 fork 一个进程不断写临时文件再删除。这两个经常一起用因为单独--io在有些内核上压力不够明显。--hdd-bytes控制每个 hdd worker 写文件的大小默认是 1G在小磁盘机器上要改小不然临时文件能把根分区撑满。3. 参数怎么调CPU、内存、I/O 三路压测的实操配置3.1 CPU 压测核数、超线程与 load 的关系CPU 压测看起来最简单但参数给多少、怎么解读结果直接决定这次压测有没有意义。先搞清楚机器有多少个逻辑核。nproc返回的是逻辑核数包含超线程。lscpu能看到物理核和每核线程数。假设一台机器nproc是 8物理核是 4开了超线程。你跑stress --cpu 88 个 worker 把 8 个逻辑核占满load average会稳定在 8 左右。如果你跑stress --cpu 4load 大概在 4 左右但 CPU 使用率可能显示 50% 上下因为超线程让每个物理核能同时跑两个线程。# 查看逻辑核数 nproc # 查看物理核与超线程拓扑 lscpu | grep -E ^CPU\(s\)|Thread|Core|Socket # 压满所有逻辑核持续 120 秒 stress --cpu $(nproc) --timeout 120s # 只压物理核数量观察超线程的增益 stress --cpu 4 --timeout 120s参数怎么定做容量基线测试时我一般先用--cpu $(nproc)压满看系统在满载下的响应延迟和调度延迟做业务模拟时按业务实际并发线程数来给比如业务是 4 线程处理就压 4别一上来就压满那样测不出真实瓶颈。观察指标压测期间用vmstat 1看r列运行队列长度和us/sy占比。r持续大于核数说明有排队sy占比高说明系统调用多、上下文切换频繁。用mpstat -P ALL 1看每个核的利用率是否均衡如果只有部分核跑满可能是进程绑核或者调度策略的问题。3.2 内存压测vm-bytes 的算法与 OOM 观察内存压测是 stress 里最容易翻车的一项因为参数算错会直接把机器打 OOM把业务进程干掉。--vm N是 worker 数量--vm-bytes SIZE是每个 worker 分配的内存大小。总内存占用约等于N × SIZE再加上 stress 自身和系统的开销。假设机器 8G 内存系统和其他进程占了 2G可用 6G。你跑--vm 4 --vm-bytes 2G总需求 8G超过可用内存OOM Killer 就会出手。# 安全的内存压测先看可用内存再按 70% 给 free -h # 假设 available 是 6G压 4G 比较安全 stress --vm 4 --vm-bytes 1G --timeout 60s # 观察 OOM 是否触发 dmesg -T | grep -i out of memory参数说明--vm-bytes支持K、M、G后缀不写后缀默认是字节写1024就是 1024 字节几乎没压力这是个常见笔误。--vm-keep参数让 worker 分配后不释放一直占着适合测内存泄漏场景不加这个参数worker 会反复分配释放压力体现在分配速度上而不是占用总量上。观察指标压测期间用free -h看available的变化用sar -r 1看内存使用率和 swap 活动。如果 swap 开始大量读写说明物理内存不够了性能会断崖式下跌。用dmesg -T看有没有 OOM 记录OOM Killer 杀了哪个进程、当时的 memory cgroup 状态是什么这些信息对定位问题很关键。3.3 I/O 压测io 与 hdd 的区别及磁盘指标I/O 压测有两个参数容易混淆--io和--hdd。--io是调用sync()把页缓存刷盘压力偏内核态--hdd是写临时文件压力偏用户态加文件系统。实际用的时候我一般两个一起上模拟真实业务的读写混合。# 混合 I/O 压测2 个 sync worker 2 个写文件 worker stress --io 2 --hdd 2 --hdd-bytes 256M --timeout 60s # 压测期间用 iostat 观察磁盘 iostat -x 1参数说明--hdd-bytes默认 1G在小磁盘或者容器环境里一定要改小不然临时文件写满磁盘stress 自己会报No space left on device然后退出压测中断。--hdd写的临时文件默认在/tmp下如果/tmp是 tmpfs内存文件系统那压的其实是内存不是磁盘这点要先用df -h /tmp确认。观察指标iostat -x 1看%util磁盘利用率和await平均等待时间。%util接近 100% 说明磁盘饱和await持续升高说明 I/O 排队严重。用iotop能看到具体是哪个进程在读写。如果是 SSD%util到 100% 不一定代表瓶颈还要看 IOPS 和吞吐量是否达到设备上限。注意在云主机上做 I/O 压测要小心云盘有 IOPS 和吞吐量配额压太狠可能触发限流影响同宿主机上的其他实例有些云厂商会发警告甚至限速。4. 避坑与排查stress 用错比不用更危险4.1 坑一没加 timeoutstress 跑飞了现象脚本里写了stress --cpu 8没带超时执行后终端卡住或者放到后台跑忘了收机器持续高负载几个小时业务受影响。原因stress 默认没有超时不加--timeout就会一直跑直到收到信号或者进程被杀。在脚本里如果没做好进程管理很容易漏掉。解决永远带--timeout哪怕是手动测试也带上。脚本里再加一层保险用timeout命令包一层比如timeout 120 stress --cpu 8双保险。跑完之后用pgrep stress确认没有残留进程有的话pkill stress清掉。4.2 坑二vm-bytes 算错把业务进程 OOM 了现象压测内存时stress 没被 OOM反而把旁边的 MySQL 或者 Java 业务进程杀了业务直接不可用。原因Linux 的 OOM Killer 选择杀哪个进程有一套打分机制不一定是杀占用内存最多的而是综合oom_score_adj、内存占用、运行时长等因素。stress 的 worker 可能因为运行时间短、分数低而逃过一劫业务进程反而中招。解决压测前先算清楚可用内存free -h看available列压测总量不要超过 available 的 70%。更稳妥的做法是用 cgroup 限制 stress 的内存让它在自己的 cgroup 里被限制OOM 也只影响这个 cgroup。临时用systemd-run起一个带内存限制的 scope# 限制 stress 最多用 2G 内存超出只杀这个 scope 里的进程 systemd-run --scope -p MemoryMax2G stress --vm 2 --vm-bytes 1G --timeout 60s4.3 坑三容器里压测压的是容器不是宿主机现象在容器里跑stress --cpu 8容器内top看到 CPU 跑满但宿主机top看这个容器的 CPU 占用只有 2 核的量。原因容器通过 cgroup 限制了 CPU 配额stress 在容器里 fork 了 8 个进程但 cgroup 只给它 2 核的配额多出来的进程在排队容器内看到的 CPU 使用率是相对于 cgroup 限制的不是宿主机的。解决明确压测目标。如果测的是容器自身的资源限制那就在容器里压看容器内的指标如果测的是宿主机的承载能力就要在宿主机上压或者用--cpus放开容器限制。用docker stats看容器的实际 CPU 和内存占用和容器内top的数据对比确认 cgroup 限制是否生效。4.4 坑四I/O 压测写满磁盘stress 自己挂了现象stress --hdd 4 --hdd-bytes 1G跑了一会儿报No space left on devicestress 退出磁盘被临时文件占满其他服务写日志失败。原因--hdd-bytes默认 1G4 个 worker 就是 4G 临时文件如果/tmp所在分区只有几个 G很快写满。stress 退出时不一定能清理干净临时文件残留下来继续占空间。解决压测前df -h /tmp确认可用空间--hdd-bytes设成可用空间的 10% 以内。压测后手动清理/tmp下的 stress 临时文件文件名一般是stress-*或者随机字符串。更规范的做法是给 stress 指定一个专门的临时目录用TMPDIR环境变量控制# 指定临时目录到独立分区避免影响根分区 TMPDIR/data/stress-tmp stress --hdd 2 --hdd-bytes 256M --timeout 60s4.5 坑五只看 load average不看实际瓶颈现象压测时load average很高但 CPU 使用率不高磁盘也不忙不知道瓶颈在哪。原因Linux 的load average统计的是运行队列长度加上不可中断睡眠D 状态的进程数。I/O 等待、锁竞争、内存回收都会让 load 升高但不一定体现在 CPU 使用率上。只看 load 会误判。解决结合多个指标一起看。vmstat 1看r运行队列、b阻塞进程、waI/O 等待、si/soswap 换入换出。pidstat -d 1看进程级 I/O。perf top看内核态热点函数。load 高但 CPU 不高优先查 I/O 和内存load 高且 CPU 高查调度和上下文切换。5. 进阶技巧用 stress-ng 补位与压测结果验证stress 本身功能有限只支持 CPU、内存、I/O、进程创建这几类。如果你需要更细粒度的压测比如指定 CPU 指令集、测网络、测文件锁stress-ng 是更现代的选择。它兼容 stress 的大部分参数同时扩展了几百种压力场景。# 安装 stress-ng sudo apt install -y stress-ng # 用 stress-ng 压 CPU 并指定方法为浮点运算 stress-ng --cpu 4 --cpu-method float --timeout 60s # 压网络启动 TCP 服务端和客户端互打 stress-ng --sock 2 --timeout 60s # 压文件锁 stress-ng --lock 4 --timeout 60s参数说明--cpu-method可以指定float、int、matrix、prime等不同算法不同算法对 CPU 流水线的压力不同测出来的功耗和发热也不一样。--sock是网络压测会 fork 进程做 TCP 收发适合测网络栈。--lock是文件锁竞争适合测多进程并发场景。压测结果怎么验证有没有效我一般做三件事。第一压测期间用sar或vmstat采集数据压测结束后看指标曲线是否和预期一致比如 CPU 压测时us应该明显上升内存压测时available应该下降。第二用perf stat看压测进程的指令数和上下文切换数确认它真的在干活而不是空转。第三压测结束后确认系统恢复正常load降下来、内存释放、临时文件清理干净没有留下副作用。# 压测前后对比关键指标 echo before uptime free -h df -h /tmp # 跑压测 stress --cpu 4 --vm 2 --vm-bytes 512M --timeout 60s echo after uptime free -h df -h /tmp pgrep stress || echo no stress process left最后说个我自己的习惯每次压测前先在测试环境跑一遍把参数和观察指标记下来形成一份自己的压测清单。生产环境压测永远带超时、永远先看 available 内存、永远准备好pkill stress的后悔药。stress 这东西用好了是照妖镜用砸了是自爆按钮区别就在参数和边界有没有算清楚。希望帮到你。本文还有配套的精品资源点击获取