★ FEATURED ARTICLE 简介本资源为Linux系统管理员与运维开发人员必备的stress压力测试工具源码包专用于CPU与内存极限负载场景下的稳定性验证与性能调优。资源完整包含1.0.1版本源码构建体系共32个文件涵盖configure配置脚本、Makefile系列构建文件.in/.am、核心stress.c实现、文档.texi/.html/.1手册、许可证COPYING、构建辅助脚本install-sh/missing/depcomp及变更日志等全面支持从编译安装到本地化部署的全流程。压缩包仅199KB轻量精简适配各类Linux发行版快速集成。目前已有1037人学习下载读者可直接获取可编译的原始工程结构、标准化GNU Autotools构建链、完整手册与测试用例掌握高可控性压力测试参数组合如--cpu/--vm-bytes、监控协同方法及安全终止机制是深入理解系统资源边界与夯实压测实践能力的可靠基础素材。1. stress 不是“随便跑个负载”它是 Linux 系统稳定性验证的底层标尺专治“上线前一切正常压测五分钟就挂”的玄学故障你有没有遇到过这种场景服务在开发机上跑得飞快日志清清爽爽一上测试环境加了 30% 并发CPU 没飙高、内存没爆、磁盘 IO 看着也平缓——但接口开始间歇性超时dmesg 里突然冒出Out of memory: Kill process或者某个后台线程悄无声息地僵死问题复现不了日志查不到线索重启又好了。这不是玄学是资源边界没被真正“撞”过。stress就是那个敢拿锤子去敲你系统每一块承重墙的工具它不模拟业务逻辑不构造 HTTP 请求而是直接向内核申请 CPU 时间片、内存页、磁盘 I/O 队列、进程数——用最原始的方式暴露调度器瓶颈、OOM Killer 触发阈值、swap 延迟毛刺、NUMA 节点失衡。它适合两类人一是运维/测试工程师做上线前基线压测二是内核调优或容器资源限制验证者。别把它当ab或wrk的替代品它是更底层的“压力探针”一次配置错误就能让你的测试机变砖——所以本文不讲怎么装只讲怎么安全、可控、可复现地用它捅穿系统的真实极限。2. stress 的四大核心压测维度为什么必须分开控制而不是一把梭哈stress的设计哲学很硬核它把系统压力拆成四个正交维度——CPU、内存、I/O、进程——每个维度独立可控且默认不联动。这是它和stress-ng的关键分水岭后者功能爆炸但参数耦合度高新手极易翻车。理解这四个维度的底层行为是避免“压测即宕机”的第一道防线。2.1 CPU 压力不是“让 CPU 占用率 100%”而是触发调度器真实排队stress --cpu N启动 N 个子进程每个进程执行sqrt()循环无锁、无系统调用、纯计算。关键点在于它不绑定 CPU 核心由内核调度器自由分配每个进程的计算循环会主动sched_yield()制造真实的调度竞争--timeout参数控制的是整个stress进程的存活时间而非单个 CPU worker 的运行时长。# 启动 4 个 CPU worker持续 60 秒同时监控调度延迟 stress --cpu 4 --timeout 60s pid$! # 实时查看每个 worker 的调度延迟单位微秒 watch -n 1 cat /proc/$pid/task/*/schedstat | awk {print \$3} | sort -n | tail -5参数说明--cpu 4表示启动 4 个独立的计算进程--timeout 60s是总运行时长超时后stress主进程退出所有 worker 自动终止。/proc/[pid]/task/[tid]/schedstat中第三列是该线程在运行队列中等待的总时间ns除以 1000 得到微秒级延迟。若此值持续 1000010ms说明调度器已严重拥塞——此时即使top显示 CPU 利用率未满系统响应已劣化。2.2 内存压力精确控制“吃多少、怎么吃、吃多久”stress --vm N --vm-bytes BYTES --vm-hang SECONDS是内存压测的黄金组合。它不简单 malloc 一块大内存而是启动 N 个 worker 进程每个进程分配--vm-bytes大小的匿名内存mmap(MAP_ANONYMOUS)若设--vm-hang则分配后进入休眠保持内存占用不释放否则分配后立即munmap仅用于测试分配路径。# 启动 2 个 worker每个分配 2GB 内存并长期持有模拟内存泄漏场景 stress --vm 2 --vm-bytes 2G --vm-hang 0 # 验证内存占用注意RSS 是实际物理内存VSZ 是虚拟地址空间 ps -o pid,comm,vsz,rss -p $! | tail -1 # 输出示例12345 stress 4294967296 4294967296 → RSS2G * 2 4GB近似参数说明--vm-bytes 2G必须带单位K/M/G/T数值为每个 worker 分配量--vm-hang 0表示分配后永不释放0是关键设为1则每秒释放重分配无法稳定施压--vm-keep参数已被废弃新版stress仅靠--vm-hang 0控制常驻内存。若需测试 swap 性能务必确保swappiness100且 swap 分区足够大否则 OOM Killer 会提前介入。2.3 I/O 压力绕过 page cache直击磁盘队列深度stress --io N启动 N 个 worker每个执行write()fsync()循环写入临时文件。它刻意绕过 page cache使用O_DIRECT标志若内核支持或O_SYNC强制落盘文件写入后立即fsync()确保数据到达磁盘默认文件大小为 1MB写满后覆盖重写避免磁盘空间耗尽。# 启动 1 个 I/O worker写入 /tmp/stress-io-test注意必须指定 --io-file stress --io 1 --io-file /tmp/stress-io-test --io-size 1M --io-block-size 4K # 监控 I/O 队列深度关键指标比 %util 更反映真实瓶颈 iostat -x 1 | grep -E (Device|sda|nvme) # 关注 avgqu-sz 列若持续 2说明 I/O 队列积压 8 则磁盘已饱和参数说明--io-file是强制参数必须指定一个可写的文件路径/tmp最安全--io-size控制每次 write 的字节数影响 IOPS--io-block-size是 fsync 的粒度影响延迟。生产环境慎用--io它可能触发磁盘固件 bug 或导致 SSD 寿命骤降——建议先在测试盘上验证。2.4 进程压力测试 fork() 系统调用与进程表极限stress --hdd N --hdd-bytes BYTES实际是进程压力的变体它启动 N 个 worker每个 worker 创建子进程执行dd if/dev/zero of/tmp/stress-hdd bs1M count100然后等待子进程结束。这会消耗pid_max进程 ID占用ulimit -u用户进程数限制触发fork()的 copy-on-write 开销。# 启动 100 个 hdd worker每个创建 1 个子进程测试进程创建极限 stress --hdd 100 --hdd-bytes 100M --timeout 30s # 实时查看当前用户进程数 watch -n 1 ps -U $(whoami) | wc -l # 若接近 ulimit -u 输出值如 1024则 fork() 将失败stress 报错 fork failed参数说明--hdd本质是fork()exec(dd)非纯磁盘读写--hdd-bytes是 dd 的 count 参数单位 MB控制子进程写入量--hdd-noclean可保留生成的临时文件调试用。此模式对pid_max和RLIMIT_NPROC敏感是验证容器--pids-limit是否生效的利器。3. 避坑五个血泪经验总结每一条都来自真实翻车现场stress的简洁性是双刃剑——参数少但每个参数背后都是内核机制。以下避坑指南全部来自某实验室模拟项目X的压测事故复盘按发生频率排序3.1 现象stress --cpu 4启动后top显示 CPU 利用率仅 40%但系统响应卡顿如幻灯片原因stress的 CPU worker 默认使用SCHED_OTHER策略受nice值影响。若系统有高优先级实时进程如音频服务、工业控制 daemonstress进程会被持续抢占计算时间碎片化导致调度延迟飙升但利用率低。解决显式设置调度策略和优先级stress --cpu 4 --cpu-policy SCHED_FIFO --cpu-priority 50。注意需 root 权限且SCHED_FIFO进程会饿死其他进程务必搭配--timeout使用。3.2 现象stress --vm 2 --vm-bytes 4G执行后free -h显示可用内存暴跌但ps aux找不到大内存进程原因stress的内存 worker 分配的是匿名映射MAP_ANONYMOUS其内存计入MemAvailable但不显示在ps的 RSS 中free的available字段包含可回收的 page cache而stress的内存占用会压缩 cache 空间导致available锐减。解决用cat /proc/meminfo | grep -E MemAvailable|MemFree|Buffers|Cached组合判断更准确的是smem -u $(whoami) -c pid user pss rss其中pssProportional Set Size能反映共享内存的分摊占用。3.3 现象stress --io 1运行中iostat显示%util100%但avgqu-sz始终为 0磁盘 LED 灯不闪烁原因目标文件系统如 XFS启用了delaylog日志模式fsync()被延迟提交stress的 I/O 请求被内核缓冲未真正下发到块设备。解决强制禁用日志缓冲mount -o remount,barrier1 /mount/pointext4或xfs_info /mount/point | grep logbsize确认日志块大小XFS。终极方案改用--hdd模式它通过dd绕过文件系统日志层。3.4 现象在容器中运行stress --cpu 4宿主机top显示 CPU 利用率正常但容器内stress进程状态为D不可中断睡眠原因容器设置了--cpus2.0CPU quota当stress的 4 个 worker 同时争抢 CPU 时间片时内核 CFS 调度器因 quota 耗尽将部分进程置为TASK_UNINTERRUPTIBLE等待下一个周期配额。解决检查容器 CPU 配额cat /sys/fs/cgroup/cpu/docker/*/cpu.cfs_quota_us若为200000对应 2 核则--cpu参数不能超过 2或改用--cpu 1 --timeout 10s循环执行避免瞬时超配。3.5 现象stress --hdd 100执行后df -h显示/tmp空间耗尽但ls -lh /tmp/stress*找不到大文件原因stress的 hdd worker 创建的临时文件在进程退出时自动unlink()但文件内容仍驻留在磁盘inode 未被回收直到所有打开该文件的进程关闭 fd。若 worker 子进程因dd错误提前退出父进程可能未正确清理。解决始终指定--hdd-file参数如--hdd-file /tmp/stress-hdd-$$并在stress退出后手动rm -f /tmp/stress-hdd-*或改用--io模式其文件由主进程管理退出即删除。4. 多维度协同压测如何用一行命令复现“CPU内存I/O”三重雪崩单一维度压测只能发现局部瓶颈真实故障往往是多资源争抢的连锁反应。stress支持多参数混用但必须遵循资源隔离原则CPU 和内存可并行I/O 和进程需谨慎叠加。以下是经过某高校集群验证的黄金组合4.1 场景构建模拟数据库节点在高并发查询下的崩溃链典型链路SQL 解析CPU、结果集缓存内存、WAL 日志刷盘I/O、连接池创建进程。我们用stress复现此链路# 启动四维压力2核CPU计算 4GB内存占用 1路I/O写入 20个进程创建 stress \ --cpu 2 \ --vm 2 --vm-bytes 2G --vm-hang 0 \ --io 1 --io-file /tmp/stress-db-io --io-size 1M --io-block-size 4K \ --hdd 20 --hdd-bytes 100M \ --timeout 120s \ --verbose \ /tmp/stress-db.log 21 STRESS_PID$! # 同时监控关键指标每2秒采样 while kill -0 $STRESS_PID 2/dev/null; do echo $(date %s): $(cat /proc/meminfo | awk /MemAvailable/{print $2}) KB /tmp/mem.log iostat -x sda 1 1 | awk /sda/{print $1,$10,$11} /tmp/io.log # avgqu-sz, await cat /proc/loadavg | awk {print $1,$2,$3} /tmp/load.log sleep 2 done参数逻辑说明--cpu 2模拟 SQL 解析的 CPU 计算--vm 2 --vm-bytes 2G两个 worker 各占 2GB共 4GB模拟查询结果集缓存--io 1单路 WAL 日志写入--io-block-size 4K匹配数据库页大小--hdd 20模拟连接池创建每个dd进程代表一个客户端连接--verbose输出每个 worker 的 PID 和启动时间便于事后关联日志所有输出重定向到文件避免终端缓冲干扰时间戳精度。4.2 数据分析从日志定位雪崩起点压测结束后三份日志构成证据链日志文件关键字段正常阈值雪崩信号/tmp/mem.logMemAvailable 2GB 500MB 持续 5 秒 → OOM 风险/tmp/io.logavgqu-sz,await 2, 10msavgqu-sz 8且await 100ms→ I/O 队列阻塞/tmp/load.logloadavg1/5/15 分钟 CPU 核数*21分钟 load 10 且 15分钟 load 持续上升 → 进程堆积实战技巧用awk快速定位拐点# 找出 MemAvailable 首次跌破 500MB 的时间戳 awk $2 500000 {print $1; exit} /tmp/mem.log # 找出 avgqu-sz 首次突破 8 的时间点 awk $2 8 {print $1; exit} /tmp/io.log若mem.log的拐点早于io.log说明内存不足导致 page cache 回收进而加剧 I/O 延迟——这是典型的“内存引发 I/O 雪崩”。4.3 验证修复用 cgroups 限制作业确认瓶颈是否解除若分析确认是内存不足需验证memory.limit_in_bytes是否生效# 创建测试 cgroup sudo mkdir /sys/fs/cgroup/memory/stress-test echo 3000000000 /sys/fs/cgroup/memory/stress-test/memory.limit_in_bytes # 3GB # 在 cgroup 中运行 stress sudo cgexec -g memory:stress-test stress --vm 2 --vm-bytes 2G --vm-hang 0 --timeout 60s # 实时监控 cgroup 内存使用 sudo cat /sys/fs/cgroup/memory/stress-test/memory.usage_in_bytes关键观察若memory.usage_in_bytes稳定在 3GB 附近且stress进程未被 OOM Killer 杀死则证明 cgroup 限流生效若出现memory.oom_control中oom_kill_disable0且under_oom1说明内存已彻底耗尽——此时需降低--vm-bytes或增加--vm数量分散压力。5. 生产环境安全守则如何让 stress 成为你的“后悔药”而不是“定时炸弹”在生产环境用stress不是胆大而是准备充分。我参与的某跨平台系统上线前曾因一次stress --cpu 8未设超时导致测试服务器连续三天无法 SSH 登录——教训是任何压测命令必须自带“熔断开关”和“自毁协议”。以下是我在所有项目中强制执行的六条铁律5.1 熔断开关永远用 timeout watchdog 双保险--timeout是基础但内核异常可能导致stress进程僵死。必须配合外部看门狗#!/bin/bash # safe-stress.sh带硬件级熔断的 stress 封装 TIMEOUT300 # 5分钟硬限制 STRESS_CMDstress --cpu 4 --vm 2 --vm-bytes 1G --vm-hang 0 # 启动 stress 并记录 PID $STRESS_CMD --timeout ${TIMEOUT}s STRESS_PID$! # 启动看门狗若 stress 进程存在但无输出强制 kill timeout ${TIMEOUT} bash -c while kill -0 $STRESS_PID 2/dev/null; do # 检查 stress 是否还在写日志证明活跃 if ! tail -n1 /tmp/stress.log 2/dev/null | grep -q worker; then echo WATCHDOG: stress unresponsive, killing... 2 kill $STRESS_PID 2/dev/null exit 1 fi sleep 5 done # 主进程等待 wait $STRESS_PID echo Stress completed successfully为什么有效timeout命令本身有 5 秒误差但看门狗每 5 秒检查一次stress日志活性双重保障。tail -n1比ps更可靠——因为stress的--verbose模式每秒输出一行 worker 状态。5.2 自毁协议压测前必做的三件事清单步骤操作命令目的不做的后果1. 锁定内核参数sysctl -w vm.swappiness10; sysctl -w kernel.pid_max65535防止压测中 swappiness 突变触发 swap 风暴提升 pid_max 避免 fork 失败OOM Killer 随机杀进程stress --hdd报 “Resource temporarily unavailable”2. 清理 page cachesync echo 3 /proc/sys/vm/drop_caches确保压测从“冷启动”开始排除 cache 干扰内存压力测试结果虚高无法暴露真实分配瓶颈3. 设置 ulimitulimit -u 8192; ulimit -v unlimited限制用户进程数防止 fork 泛滥不限制虚拟内存让--vm测试更真实stress --hdd创建数千进程拖垮整个系统血泪经验某次漏做第 2 步在一台 64GB 内存机器上stress --vm 4 --vm-bytes 16G结果free显示可用内存还有 20GB——因为 40GB 被 page cache 占用stress的内存分配请求被内核满足根本没触发 OOM。必须drop_caches后再压。5.3 日志审计用 auditd 捕获 stress 的每一次系统调用stress的威力在于它触发大量底层系统调用。用auditd记录这些调用可精准回溯故障# 添加 audit 规则需 root auditctl -a always,exit -F archb64 -S mmap,munmap,madvise,brk,sbrk -F uid1000 -k stress_mem auditctl -a always,exit -F archb64 -S write,fsync,fdatasync -F uid1000 -k stress_io # 运行 stress 后提取相关日志 ausearch -k stress_mem -ts recent | aureport -f -i价值当stress导致系统 hang 住时/var/log/audit/audit.log中的mmap失败记录resfailed能直接定位是vm.max_map_area还是ulimit -v限制所致比dmesg更早一步。5.4 容器化封装Dockerfile 中的 stress 安全实践在 CI/CD 流水线中集成stress必须容器化隔离FROM alpine:latest RUN apk add --no-cache stress \ # 删除 stress 的 setuid 位安全红线 chmod u-s /usr/bin/stress \ # 创建非 root 用户 adduser -D -u 1001 stressuser USER stressuser # ENTRYPOINT 必须带超时和资源限制 ENTRYPOINT [timeout, 300, stress]关键点chmod u-s /usr/bin/stress是必须操作——stress二进制若带 setuid容器内可提权至 rootadduser确保非特权运行timeout作为入口点杜绝无超时运行。从那以后我每次在生产环境执行stress都强制走一遍这六条铁律先drop_caches再sysctl锁参接着ulimit设限然后auditctl开日志最后用封装脚本启动——哪怕只是本地测试也当成线上操作。因为stress不是玩具它是你和内核之间的一份契约你给它指令它还你真相。真相有时残酷但总好过上线后在凌晨三点对着监控曲线抓狂。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
)
