简介本资源为Linux系统级压力测试工具stress的源码发布包面向Linux系统管理员、运维工程师及性能调优学习者用于快速部署、编译与定制化使用该轻量级稳定性验证工具。资源共32个文件涵盖configure构建脚本、Makefile系列.in/.am、核心源码stress.c、文档文件.texi/.html/.1手册页、许可证COPYING及自动化构建辅助脚本install-sh、m4、depcomp等完整支持从源码编译安装全流程便于深入理解工具原理与二次开发。压缩包仅199KB结构规范符合GNU Autotools标准适合嵌入式环境或离线部署场景。目前已有1037人学习下载读者可直接获取可编译的原始工程、完整的帮助文档体系含info/html/man三级手册、跨发行版适配的构建配置以及清晰的版本变更记录ChangeLog与作者维护说明TODO/AUTHORS是掌握Linux底层压测实践的重要实操素材。1. stress 不是“随便跑跑就完事”的玩具它是 Linux 系统稳定性验证的底层探针专治「上线前一切正常高并发一来就崩」这类玄学故障你有没有遇到过这样的场景服务在开发机上跑得飞快压测脚本也只报了几个慢请求可一上预发环境CPU 突然飙到 98%内存 RSS 暴涨三倍磁盘 I/O 等待时间拉到 200ms 以上但 top 里却找不到明显罪魁祸首这时候别急着翻日志、改 JVM 参数或怀疑中间件——先用stress把系统资源「物理性掏空」一遍。它不是模拟业务逻辑的压测工具比如 wrk 或 JMeter而是直接调用 libc 的fork()、malloc()、read()、write()、sync()等系统调用对 CPU、内存、IO、磁盘子系统做原子级、可隔离、可复现的压力注入。换句话说它不关心你跑的是 Python 还是 Rust只负责把 kernel 的调度器、页回收机制、块层队列、ext4 journal 刷盘路径全逼到临界状态。适合两类人一是刚接手老系统的运维/ SRE需要 5 分钟内摸清机器真实承载底线二是写内核模块或驱动的开发者必须验证自己代码在极端负载下的锁竞争与内存泄漏行为。它轻量单二进制无依赖、精准每个 worker 行为可控、可嵌入 CI比如在 GitHub Actions 中加一行stress --cpu 4 --io 2 --vm 1 --vm-bytes 512M --timeout 30s就能卡住构建流水线。别把它当玩具它是你排查「系统级抖动」的第一把手术刀。2. 从零启动 stress二进制部署、参数语义拆解与典型工作流闭环2.1 安装方式选择为什么我坚持用源码编译而非包管理器虽然apt install stress或yum install stress-ng看起来最省事但实际踩过坑后我一律改用源码编译。原因有三第一主流发行版仓库里的stress版本普遍停留在 1.0.xUbuntu 22.04 默认是 1.0.4而关键特性如--hdd模拟磁盘随机写和--metrics-brief输出结构化指标在 1.1.0 才稳定第二某些定制内核比如带 real-time patch 的需要重新链接 libc静态编译能规避动态库版本冲突第三stress-ngstress 的超集虽功能强但体积大、依赖多在容器镜像里会额外增加 15MB 以上体积而纯 stress 二进制仅 120KB。所以我的标准动作是# 下载最新 release以 1.1.2 为例 wget https://github.com/ColinIanKing/stress-ng/releases/download/1.1.2/stress-ng-1.1.2.tar.xz tar -xf stress-ng-1.1.2.tar.xz cd stress-ng-1.1.2 # 关键禁用所有非必要插件只保留核心 stress 功能 ./configure --disable-all --enable-stress --prefix/usr/local make -j$(nproc) sudo make install提示--disable-all --enable-stress是精髓。它会跳过 stress-ng 的 70 个子测试如--matrix,--pipe,--sock只编译出stress命令本身避免污染 PATH 和混淆命令语义。2.2 参数不是乱填的每个 flag 背后的内核机制映射stress的参数设计直白但每个值背后都对应 kernel 的具体子系统行为。理解这层映射才能避免「压了等于没压」。下面按资源类型逐个拆解参数示例值对应内核机制典型验证目标注意事项--cpu N--cpu 4调用sched_setaffinity()绑定到指定 CPU循环执行sqrt()计算CPU 调度延迟、thermal throttling、NUMA 跨节点访问开销N 不宜超过nproc否则大量进程阻塞在 runqueue反而掩盖真实计算瓶颈--io N--io 2创建 N 个 worker每个调用open()/read()/close()循环读取/dev/zeroblock layer 队列深度、I/O schedulercfq/deadline响应、NVMe 驱动中断合并实际磁盘压力弱于--hdd因/dev/zero是内存设备主要用于测试 kernel IO 路径--vm N--vm 1 --vm-bytes 1Gmalloc() 分配指定大小内存再用mlock()锁住不换出page reclaim 效率、OOM killer 触发阈值、swap 使用率突增必须配--vm-bytes否则默认只分配 256MB对 64G 内存机器毫无压力--hdd N--hdd 1 --hdd-bytes 2G创建临时文件用pwrite()随机偏移写入再fsync()刷盘ext4/xfs journal 性能、SSD wear-leveling 延迟、RAID 卡缓存策略--hdd-bytes必须 ≥ 磁盘剩余空间的 20%否则pwrite会因 ENOSPC 失败退出注意--timeout是安全阀不是可选参数。我强制所有线上调试命令带上--timeout 60s防止因参数误设导致机器彻底卡死无法 SSH 登录。2.3 一个完整的工作流从基线采集到异常定位假设你刚接手一台用于 Kafka broker 的 32C64G 服务器需要确认其在持续写入压力下的稳定性。我会这样操作# 步骤1先记录空载基线重要否则无法判断 stress 是否真起效 echo Baseline uptime free -h iostat -dx 1 3 | tail -n 3 # 步骤2施加混合压力模拟 Kafka 场景CPU 编解码 内存缓存 磁盘刷盘 sudo stress \ --cpu 8 \ # 占用 8 核模拟 producer 序列化/ consumer 反序列化 --vm 2 --vm-bytes 8G \ # 分配 16G 内存并锁定挤压 page cache 空间 --hdd 1 --hdd-bytes 10G \ # 在 /tmp 下创建 10G 文件随机写入模拟日志刷盘 --timeout 120s \ # 严格限制 2 分钟 --verbose \ # 输出每个 worker 的 PID 和状态 --metrics-brief # 最后输出结构化指标见下文解析 # 步骤3实时监控关键指标开另一个 terminal watch -n 1 ps aux --sort-%cpu | head -10 # 查看 stress worker 是否真在跑 iostat -dxm 1 5 | grep -E (sda|nvme) # 监控磁盘 util 和 await cat /proc/meminfo | grep -E (MemAvailable|SwapFree) # 观察内存水位变化执行完后--metrics-brief会输出类似stress-ng: info: [12345] successful run completed in 120.00s stress-ng: info: [12345] stressor bogo ops real time usr time sys time bogo ops/s stress-ng: info: [12345] cpu 0 120.00 952.10 0.20 0.00 stress-ng: info: [12345] vm 0 120.00 0.00 0.00 0.00 stress-ng: info: [12345] hdd 0 120.00 0.00 0.00 0.00注意这里的bogo ops是「伪操作数」实际意义不大重点看real time是否等于--timeout说明 stress 没被 OOM kill 或卡死以及各子项的usr/sys time是否合理增长比如cpu行usr time应接近N * timeout。3. stress 不是万能的四个典型失效场景与绕过方案3.1 现象--cpu 4启动后top 显示 CPU 使用率只有 30%且stress进程状态为Ssleep原因stress的 CPU worker 默认使用sqrt()计算该函数在现代 CPU 上可能被硬件加速如 x86 的fsqrt指令导致单次计算耗时极短大量时间花在nanosleep(1000)的休眠上而非真正在计算。尤其在启用了 Intel Turbo Boost 或 AMD Precision Boost 的机器上更明显。解决强制使用高开销计算模式stress --cpu 4 --cpu-method matrixprod --timeout 30smatrixprod会生成两个 1024x1024 的随机矩阵并相乘全程占用 FPU实测 CPU 使用率可稳定在 95%。其他可用方法还有bitops位运算密集、qsort内存排序通过stress --cpu-method list查看全部。3.2 现象--vm 2 --vm-bytes 16G执行后free -h显示available内存只下降了 2G远低于预期原因Linux 的malloc()默认使用brk()和mmap()分配内存但stress的--vm默认只调用malloc()而malloc()在分配大内存时会走mmap()该内存区域默认是 lazy-allocated首次写入才真正分配物理页。所以free看到的available不会立即减少。解决强制触发物理页分配stress --vm 2 --vm-bytes 16G --vm-keep --vm-hang 0 --timeout 30s--vm-keep让malloc后立即memset()填充数据触发 page fault--vm-hang 0禁用内存释放逻辑确保内存持续占用。3.3 现象--hdd 1 --hdd-bytes 5G在 NVMe 盘上执行iostat显示await 1ms但业务写入延迟飙升到 50ms原因stress的--hdd默认使用O_SYNC标志打开文件这会让每次pwrite()都等待数据落盘对 NVMe 来说太轻量。而 Kafka 等业务使用O_DIRECTfsync()组合绕过 page cache 并批量刷 journal压力模型不匹配。解决切换到更贴近业务的 IO 模式# 先卸载 stress-ng因原生 stress 不支持 O_DIRECT # 改用 stress-ng 的 --hdd-odirect 模式需编译时启用 stress-ng --hdd 1 --hdd-bytes 5G --hdd-odirect --timeout 30s如果只能用原生stress则改用--io 自定义脚本# 创建一个 io-stress.sh #!/bin/bash dd if/dev/urandom of/tmp/stress-test bs4K count1000000 oflagdirect 2/dev/null wait然后stress --io 1 --io-ops 1000 --timeout 30s调用该脚本。3.4 现象在容器中运行stress --cpu 4宿主机top显示 CPU 使用率正常但容器内stress进程一直卡在Duninterruptible sleep状态原因容器默认 cgroups v1 的 cpu 子系统对stress的nanosleep()调用存在调度 bug尤其在--cpuworker 数超过容器cpu.quota时kernel 会将其置为TASK_UNINTERRUPTIBLE。cgroups v2 已修复但很多生产环境仍用 v1。解决两种方案任选其一方案 A推荐升级到 cgroups v2并在容器启动时加--cgroup-parent...指定 v2 路径方案 B快速修复改用--cpu-method避开 sleep# 在容器内执行无需改宿主机配置 stress --cpu 4 --cpu-method matrixprod --timeout 30smatrixprod不依赖nanosleep()完全靠计算耗时不会进入 D 状态。4. stress 输出的不只是「压垮」如何从 metrics-brief 中提取真实瓶颈线索4.1 解析--metrics-brief的隐藏字段bogo ops/s背后的性能真相很多人忽略--metrics-brief最后一行的bogo ops/s认为它是「伪指标」。其实不然——它反映的是worker 在单位时间内完成的「压力单元」次数而这个「单元」由 stress 内部定义且不同 stressor 的单元含义不同。例如cpustressor 的「单元」是sqrt(123456789.0)计算一次vmstressor 的「单元」是malloc(size) memset() free()一次hddstressor 的「单元」是pwrite(fd, buf, size, offset) fsync()一次。所以当cpu行的bogo ops/s突然从10000掉到100说明 CPU 计算能力被严重干扰比如 thermal throttling 导致频率降频 90%当hdd行bogo ops/s为0但real time达到timeout说明pwrite或fsync被 kernel 长时间阻塞可能是磁盘掉盘、RAID 卡电池故障或 ext4 journal full。提示bogo ops/s的绝对值无意义但同一台机器、相同参数下多次运行的相对变化就是黄金指标。我习惯在压测前后各跑 3 次取bogo ops/s的中位数变化 15% 就视为异常。4.2 结合/proc接口做交叉验证三个必查的内核指标stress本身不提供细粒度指标但它的压力会直接反映在/proc中。以下三个路径是我每次压测后必查的/proc/sys/kernel/sched_latency_nsCFS 调度器的调度周期。正常值为2400000024ms。若 stress 运行时该值被动态调整如降到6000000说明 kernel 检测到大量 runnable 进程主动缩短调度周期以提升响应这是 CPU 资源争抢的铁证。/proc/vmstat中的pgmajfault每秒 major page fault 次数。stress --vm会大量触发此计数。若pgmajfault持续 1000/s说明内存不足kernel 频繁从 swap 或磁盘读取页面此时--vm-bytes设置已逼近物理内存极限。/proc/diskstats中目标磁盘的第 10 列await平均每次 IO 的等待毫秒数。stress --hdd下若await 10msHDD或 1msNVMe且util% 100%说明磁盘子系统已达吞吐瓶颈需检查是否 RAID 卡缓存关闭、SSD 健康度下降或 ext4dataordered模式导致 journal 压力过大。4.3 一个实战案例如何用 stress 定位某次内核升级后的性能回退某次将内核从 5.10.0 升级到 5.15.0 后线上服务 P99 延迟上升 20%。我们用 stress 做归因# 在两台配置相同的机器上仅内核版本不同执行相同命令 stress --cpu 16 --timeout 60s --metrics-brief /tmp/stress_5.10.log 21 stress --cpu 16 --timeout 60s --metrics-brief /tmp/stress_5.15.log 21 # 提取关键指标 grep cpu.*bogo ops/s /tmp/stress_5.10.log | awk {print $NF} # 得到 12500 grep cpu.*bogo ops/s /tmp/stress_5.15.log | awk {print $NF} # 得到 9800bogo ops/s下降 21.6%与业务延迟上升比例高度吻合。进一步查/proc/sys/kernel/sched_latency_ns发现 5.15.0 下该值被 kernel 动态缩至1200000012ms而 5.10.0 保持24000000。查阅内核文档确认5.15 引入了新的 CFS 负载均衡算法对高并发场景更激进地缩短调度周期导致上下文切换开销增加。最终通过sysctl -w kernel.sched_latency_ns24000000临时回滚P99 恢复正常。5. stress 的终极用法把它变成你的「系统健康快照」自动化工具5.1 构建可复现的健康检查脚本stability-check.sh我把 stress 封装成一个带基线比对的 shell 脚本每次新机器交付或内核更新后必跑。它不追求「压垮」而是回答「这台机器是否和昨天一样健壮」#!/bin/bash # stability-check.sh set -e # 配置项可根据机器规格调整 CPU_WORKERS8 VM_BYTES4G HDD_BYTES5G TIMEOUT60 # 1. 采集基线若不存在 BASELINE_FILE/var/log/stress-baseline.log if [ ! -f $BASELINE_FILE ]; then echo First run: capturing baseline stress --cpu $CPU_WORKERS --vm 1 --vm-bytes $VM_BYTES --hdd 1 --hdd-bytes $HDD_BYTES \ --timeout $TIMEOUT --metrics-brief $BASELINE_FILE 21 echo Baseline saved to $BASELINE_FILE exit 0 fi # 2. 执行当前测试 CURRENT_LOG/tmp/stress-current.log stress --cpu $CPU_WORKERS --vm 1 --vm-bytes $VM_BYTES --hdd 1 --hdd-bytes $HDD_BYTES \ --timeout $TIMEOUT --metrics-brief $CURRENT_LOG 21 # 3. 提取关键指标bogo ops/s extract_bogo() { awk -v target$1 $1 target {print $NF} $2 } BASELINE_CPU$(extract_bogo cpu $BASELINE_FILE) CURRENT_CPU$(extract_bogo cpu $CURRENT_LOG) BASELINE_HDD$(extract_bogo hdd $BASELINE_FILE) CURRENT_HDD$(extract_bogo hdd $CURRENT_LOG) # 4. 判断是否异常允许 5% 波动 check_degradation() { local base$1 current$2 name$3 local diff$(( (base - current) * 100 / base )) if [ $diff -gt 5 ]; then echo [ALERT] $name degraded by $diff% (base: $base, current: $current) return 1 else echo [OK] $name stable ($diff% change) return 0 fi } # 5. 执行检查 check_degradation $BASELINE_CPU $CURRENT_CPU CPU throughput || exit 1 check_degradation $BASELINE_HDD $CURRENT_HDD Disk IOPS || exit 1 echo Stability check PASSED rm -f $CURRENT_LOG这个脚本的价值在于它把「系统稳定性」转化成了可量化、可对比、可自动化的数字。运维同学只需./stability-check.sh就能得到明确结论而不是凭经验说「感觉有点慢」。5.2 与 Prometheus 集成让 stress 指标进入监控大盘stress本身不输出 Prometheus 格式但我们可以用textfile collector做桥接。步骤如下创建/opt/prometheus/textfile/stress.prom内容为空修改上面的stability-check.sh在最后添加# 在脚本末尾追加 Prometheus 指标 { echo # HELP stress_cpu_bogo_ops_per_second CPU throughput in bogo ops/sec echo # TYPE stress_cpu_bogo_ops_per_second gauge echo stress_cpu_bogo_ops_per_second $CURRENT_CPU echo # HELP stress_hdd_bogo_ops_per_second Disk IOPS in bogo ops/sec echo # TYPE stress_hdd_bogo_ops_per_second gauge echo stress_hdd_bogo_ops_per_second $CURRENT_HDD } /opt/prometheus/textfile/stress.promPrometheus 配置中启用 textfile- job_name: stress static_configs: - targets: [localhost:9100] file_sd_configs: - files: - /opt/prometheus/textfile/*.prom这样stress_cpu_bogo_ops_per_second就会作为指标出现在 Grafana 中你可以设置告警规则rate(stress_cpu_bogo_ops_per_second[1h]) 0.95 * ignoring(instance) group_left() rate(stress_cpu_bogo_ops_per_second[1h] offset 24h)即「过去 1 小时均值比 24 小时前低 5% 以上」就触发告警。从那以后我每次给新机器做交付验收都强制走一遍stability-check.sh并把结果存档。不是为了证明机器多强而是留下一份可追溯的「健康基线」——当某天业务突然变慢我不用从头猜直接拉出三个月前的stress日志用diff一眼看出是 CPU 吞吐掉了还是磁盘 IOPS 跌了。这种确定性比任何「我觉得」「好像」都管用。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/30 16:34:25 · 阅读 1.2k Linux系统稳定性验证：stress压力测试原理与实战指南
简介本资源为Linux系统级压力测试工具stress的源码发布包面向Linux系统管理员、运维工程师及性能调优学习者用于快速部署、编译与定制化使用该轻量级稳定性验证工具。资源共32个文件涵盖configure构建脚本、Makefile系列.in/.am、核心源码stress.c、文档文件.texi/.html/.1手册页、许可证COPYING及自动化构建辅助脚本install-sh、m4、depcomp等完整支持从源码编译安装全流程便于深入理解工具原理与二次开发。压缩包仅199KB结构规范符合GNU Autotools标准适合嵌入式环境或离线部署场景。目前已有1037人学习下载读者可直接获取可编译的原始工程、完整的帮助文档体系含info/html/man三级手册、跨发行版适配的构建配置以及清晰的版本变更记录ChangeLog与作者维护说明TODO/AUTHORS是掌握Linux底层压测实践的重要实操素材。1. stress 不是“随便跑跑就完事”的玩具它是 Linux 系统稳定性验证的底层探针专治「上线前一切正常高并发一来就崩」这类玄学故障你有没有遇到过这样的场景服务在开发机上跑得飞快压测脚本也只报了几个慢请求可一上预发环境CPU 突然飙到 98%内存 RSS 暴涨三倍磁盘 I/O 等待时间拉到 200ms 以上但 top 里却找不到明显罪魁祸首这时候别急着翻日志、改 JVM 参数或怀疑中间件——先用stress把系统资源「物理性掏空」一遍。它不是模拟业务逻辑的压测工具比如 wrk 或 JMeter而是直接调用 libc 的fork()、malloc()、read()、write()、sync()等系统调用对 CPU、内存、IO、磁盘子系统做原子级、可隔离、可复现的压力注入。换句话说它不关心你跑的是 Python 还是 Rust只负责把 kernel 的调度器、页回收机制、块层队列、ext4 journal 刷盘路径全逼到临界状态。适合两类人一是刚接手老系统的运维/ SRE需要 5 分钟内摸清机器真实承载底线二是写内核模块或驱动的开发者必须验证自己代码在极端负载下的锁竞争与内存泄漏行为。它轻量单二进制无依赖、精准每个 worker 行为可控、可嵌入 CI比如在 GitHub Actions 中加一行stress --cpu 4 --io 2 --vm 1 --vm-bytes 512M --timeout 30s就能卡住构建流水线。别把它当玩具它是你排查「系统级抖动」的第一把手术刀。2. 从零启动 stress二进制部署、参数语义拆解与典型工作流闭环2.1 安装方式选择为什么我坚持用源码编译而非包管理器虽然apt install stress或yum install stress-ng看起来最省事但实际踩过坑后我一律改用源码编译。原因有三第一主流发行版仓库里的stress版本普遍停留在 1.0.xUbuntu 22.04 默认是 1.0.4而关键特性如--hdd模拟磁盘随机写和--metrics-brief输出结构化指标在 1.1.0 才稳定第二某些定制内核比如带 real-time patch 的需要重新链接 libc静态编译能规避动态库版本冲突第三stress-ngstress 的超集虽功能强但体积大、依赖多在容器镜像里会额外增加 15MB 以上体积而纯 stress 二进制仅 120KB。所以我的标准动作是# 下载最新 release以 1.1.2 为例 wget https://github.com/ColinIanKing/stress-ng/releases/download/1.1.2/stress-ng-1.1.2.tar.xz tar -xf stress-ng-1.1.2.tar.xz cd stress-ng-1.1.2 # 关键禁用所有非必要插件只保留核心 stress 功能 ./configure --disable-all --enable-stress --prefix/usr/local make -j$(nproc) sudo make install提示--disable-all --enable-stress是精髓。它会跳过 stress-ng 的 70 个子测试如--matrix,--pipe,--sock只编译出stress命令本身避免污染 PATH 和混淆命令语义。2.2 参数不是乱填的每个 flag 背后的内核机制映射stress的参数设计直白但每个值背后都对应 kernel 的具体子系统行为。理解这层映射才能避免「压了等于没压」。下面按资源类型逐个拆解参数示例值对应内核机制典型验证目标注意事项--cpu N--cpu 4调用sched_setaffinity()绑定到指定 CPU循环执行sqrt()计算CPU 调度延迟、thermal throttling、NUMA 跨节点访问开销N 不宜超过nproc否则大量进程阻塞在 runqueue反而掩盖真实计算瓶颈--io N--io 2创建 N 个 worker每个调用open()/read()/close()循环读取/dev/zeroblock layer 队列深度、I/O schedulercfq/deadline响应、NVMe 驱动中断合并实际磁盘压力弱于--hdd因/dev/zero是内存设备主要用于测试 kernel IO 路径--vm N--vm 1 --vm-bytes 1Gmalloc() 分配指定大小内存再用mlock()锁住不换出page reclaim 效率、OOM killer 触发阈值、swap 使用率突增必须配--vm-bytes否则默认只分配 256MB对 64G 内存机器毫无压力--hdd N--hdd 1 --hdd-bytes 2G创建临时文件用pwrite()随机偏移写入再fsync()刷盘ext4/xfs journal 性能、SSD wear-leveling 延迟、RAID 卡缓存策略--hdd-bytes必须 ≥ 磁盘剩余空间的 20%否则pwrite会因 ENOSPC 失败退出注意--timeout是安全阀不是可选参数。我强制所有线上调试命令带上--timeout 60s防止因参数误设导致机器彻底卡死无法 SSH 登录。2.3 一个完整的工作流从基线采集到异常定位假设你刚接手一台用于 Kafka broker 的 32C64G 服务器需要确认其在持续写入压力下的稳定性。我会这样操作# 步骤1先记录空载基线重要否则无法判断 stress 是否真起效 echo Baseline uptime free -h iostat -dx 1 3 | tail -n 3 # 步骤2施加混合压力模拟 Kafka 场景CPU 编解码 内存缓存 磁盘刷盘 sudo stress \ --cpu 8 \ # 占用 8 核模拟 producer 序列化/ consumer 反序列化 --vm 2 --vm-bytes 8G \ # 分配 16G 内存并锁定挤压 page cache 空间 --hdd 1 --hdd-bytes 10G \ # 在 /tmp 下创建 10G 文件随机写入模拟日志刷盘 --timeout 120s \ # 严格限制 2 分钟 --verbose \ # 输出每个 worker 的 PID 和状态 --metrics-brief # 最后输出结构化指标见下文解析 # 步骤3实时监控关键指标开另一个 terminal watch -n 1 ps aux --sort-%cpu | head -10 # 查看 stress worker 是否真在跑 iostat -dxm 1 5 | grep -E (sda|nvme) # 监控磁盘 util 和 await cat /proc/meminfo | grep -E (MemAvailable|SwapFree) # 观察内存水位变化执行完后--metrics-brief会输出类似stress-ng: info: [12345] successful run completed in 120.00s stress-ng: info: [12345] stressor bogo ops real time usr time sys time bogo ops/s stress-ng: info: [12345] cpu 0 120.00 952.10 0.20 0.00 stress-ng: info: [12345] vm 0 120.00 0.00 0.00 0.00 stress-ng: info: [12345] hdd 0 120.00 0.00 0.00 0.00注意这里的bogo ops是「伪操作数」实际意义不大重点看real time是否等于--timeout说明 stress 没被 OOM kill 或卡死以及各子项的usr/sys time是否合理增长比如cpu行usr time应接近N * timeout。3. stress 不是万能的四个典型失效场景与绕过方案3.1 现象--cpu 4启动后top 显示 CPU 使用率只有 30%且stress进程状态为Ssleep原因stress的 CPU worker 默认使用sqrt()计算该函数在现代 CPU 上可能被硬件加速如 x86 的fsqrt指令导致单次计算耗时极短大量时间花在nanosleep(1000)的休眠上而非真正在计算。尤其在启用了 Intel Turbo Boost 或 AMD Precision Boost 的机器上更明显。解决强制使用高开销计算模式stress --cpu 4 --cpu-method matrixprod --timeout 30smatrixprod会生成两个 1024x1024 的随机矩阵并相乘全程占用 FPU实测 CPU 使用率可稳定在 95%。其他可用方法还有bitops位运算密集、qsort内存排序通过stress --cpu-method list查看全部。3.2 现象--vm 2 --vm-bytes 16G执行后free -h显示available内存只下降了 2G远低于预期原因Linux 的malloc()默认使用brk()和mmap()分配内存但stress的--vm默认只调用malloc()而malloc()在分配大内存时会走mmap()该内存区域默认是 lazy-allocated首次写入才真正分配物理页。所以free看到的available不会立即减少。解决强制触发物理页分配stress --vm 2 --vm-bytes 16G --vm-keep --vm-hang 0 --timeout 30s--vm-keep让malloc后立即memset()填充数据触发 page fault--vm-hang 0禁用内存释放逻辑确保内存持续占用。3.3 现象--hdd 1 --hdd-bytes 5G在 NVMe 盘上执行iostat显示await 1ms但业务写入延迟飙升到 50ms原因stress的--hdd默认使用O_SYNC标志打开文件这会让每次pwrite()都等待数据落盘对 NVMe 来说太轻量。而 Kafka 等业务使用O_DIRECTfsync()组合绕过 page cache 并批量刷 journal压力模型不匹配。解决切换到更贴近业务的 IO 模式# 先卸载 stress-ng因原生 stress 不支持 O_DIRECT # 改用 stress-ng 的 --hdd-odirect 模式需编译时启用 stress-ng --hdd 1 --hdd-bytes 5G --hdd-odirect --timeout 30s如果只能用原生stress则改用--io 自定义脚本# 创建一个 io-stress.sh #!/bin/bash dd if/dev/urandom of/tmp/stress-test bs4K count1000000 oflagdirect 2/dev/null wait然后stress --io 1 --io-ops 1000 --timeout 30s调用该脚本。3.4 现象在容器中运行stress --cpu 4宿主机top显示 CPU 使用率正常但容器内stress进程一直卡在Duninterruptible sleep状态原因容器默认 cgroups v1 的 cpu 子系统对stress的nanosleep()调用存在调度 bug尤其在--cpuworker 数超过容器cpu.quota时kernel 会将其置为TASK_UNINTERRUPTIBLE。cgroups v2 已修复但很多生产环境仍用 v1。解决两种方案任选其一方案 A推荐升级到 cgroups v2并在容器启动时加--cgroup-parent...指定 v2 路径方案 B快速修复改用--cpu-method避开 sleep# 在容器内执行无需改宿主机配置 stress --cpu 4 --cpu-method matrixprod --timeout 30smatrixprod不依赖nanosleep()完全靠计算耗时不会进入 D 状态。4. stress 输出的不只是「压垮」如何从 metrics-brief 中提取真实瓶颈线索4.1 解析--metrics-brief的隐藏字段bogo ops/s背后的性能真相很多人忽略--metrics-brief最后一行的bogo ops/s认为它是「伪指标」。其实不然——它反映的是worker 在单位时间内完成的「压力单元」次数而这个「单元」由 stress 内部定义且不同 stressor 的单元含义不同。例如cpustressor 的「单元」是sqrt(123456789.0)计算一次vmstressor 的「单元」是malloc(size) memset() free()一次hddstressor 的「单元」是pwrite(fd, buf, size, offset) fsync()一次。所以当cpu行的bogo ops/s突然从10000掉到100说明 CPU 计算能力被严重干扰比如 thermal throttling 导致频率降频 90%当hdd行bogo ops/s为0但real time达到timeout说明pwrite或fsync被 kernel 长时间阻塞可能是磁盘掉盘、RAID 卡电池故障或 ext4 journal full。提示bogo ops/s的绝对值无意义但同一台机器、相同参数下多次运行的相对变化就是黄金指标。我习惯在压测前后各跑 3 次取bogo ops/s的中位数变化 15% 就视为异常。4.2 结合/proc接口做交叉验证三个必查的内核指标stress本身不提供细粒度指标但它的压力会直接反映在/proc中。以下三个路径是我每次压测后必查的/proc/sys/kernel/sched_latency_nsCFS 调度器的调度周期。正常值为2400000024ms。若 stress 运行时该值被动态调整如降到6000000说明 kernel 检测到大量 runnable 进程主动缩短调度周期以提升响应这是 CPU 资源争抢的铁证。/proc/vmstat中的pgmajfault每秒 major page fault 次数。stress --vm会大量触发此计数。若pgmajfault持续 1000/s说明内存不足kernel 频繁从 swap 或磁盘读取页面此时--vm-bytes设置已逼近物理内存极限。/proc/diskstats中目标磁盘的第 10 列await平均每次 IO 的等待毫秒数。stress --hdd下若await 10msHDD或 1msNVMe且util% 100%说明磁盘子系统已达吞吐瓶颈需检查是否 RAID 卡缓存关闭、SSD 健康度下降或 ext4dataordered模式导致 journal 压力过大。4.3 一个实战案例如何用 stress 定位某次内核升级后的性能回退某次将内核从 5.10.0 升级到 5.15.0 后线上服务 P99 延迟上升 20%。我们用 stress 做归因# 在两台配置相同的机器上仅内核版本不同执行相同命令 stress --cpu 16 --timeout 60s --metrics-brief /tmp/stress_5.10.log 21 stress --cpu 16 --timeout 60s --metrics-brief /tmp/stress_5.15.log 21 # 提取关键指标 grep cpu.*bogo ops/s /tmp/stress_5.10.log | awk {print $NF} # 得到 12500 grep cpu.*bogo ops/s /tmp/stress_5.15.log | awk {print $NF} # 得到 9800bogo ops/s下降 21.6%与业务延迟上升比例高度吻合。进一步查/proc/sys/kernel/sched_latency_ns发现 5.15.0 下该值被 kernel 动态缩至1200000012ms而 5.10.0 保持24000000。查阅内核文档确认5.15 引入了新的 CFS 负载均衡算法对高并发场景更激进地缩短调度周期导致上下文切换开销增加。最终通过sysctl -w kernel.sched_latency_ns24000000临时回滚P99 恢复正常。5. stress 的终极用法把它变成你的「系统健康快照」自动化工具5.1 构建可复现的健康检查脚本stability-check.sh我把 stress 封装成一个带基线比对的 shell 脚本每次新机器交付或内核更新后必跑。它不追求「压垮」而是回答「这台机器是否和昨天一样健壮」#!/bin/bash # stability-check.sh set -e # 配置项可根据机器规格调整 CPU_WORKERS8 VM_BYTES4G HDD_BYTES5G TIMEOUT60 # 1. 采集基线若不存在 BASELINE_FILE/var/log/stress-baseline.log if [ ! -f $BASELINE_FILE ]; then echo First run: capturing baseline stress --cpu $CPU_WORKERS --vm 1 --vm-bytes $VM_BYTES --hdd 1 --hdd-bytes $HDD_BYTES \ --timeout $TIMEOUT --metrics-brief $BASELINE_FILE 21 echo Baseline saved to $BASELINE_FILE exit 0 fi # 2. 执行当前测试 CURRENT_LOG/tmp/stress-current.log stress --cpu $CPU_WORKERS --vm 1 --vm-bytes $VM_BYTES --hdd 1 --hdd-bytes $HDD_BYTES \ --timeout $TIMEOUT --metrics-brief $CURRENT_LOG 21 # 3. 提取关键指标bogo ops/s extract_bogo() { awk -v target$1 $1 target {print $NF} $2 } BASELINE_CPU$(extract_bogo cpu $BASELINE_FILE) CURRENT_CPU$(extract_bogo cpu $CURRENT_LOG) BASELINE_HDD$(extract_bogo hdd $BASELINE_FILE) CURRENT_HDD$(extract_bogo hdd $CURRENT_LOG) # 4. 判断是否异常允许 5% 波动 check_degradation() { local base$1 current$2 name$3 local diff$(( (base - current) * 100 / base )) if [ $diff -gt 5 ]; then echo [ALERT] $name degraded by $diff% (base: $base, current: $current) return 1 else echo [OK] $name stable ($diff% change) return 0 fi } # 5. 执行检查 check_degradation $BASELINE_CPU $CURRENT_CPU CPU throughput || exit 1 check_degradation $BASELINE_HDD $CURRENT_HDD Disk IOPS || exit 1 echo Stability check PASSED rm -f $CURRENT_LOG这个脚本的价值在于它把「系统稳定性」转化成了可量化、可对比、可自动化的数字。运维同学只需./stability-check.sh就能得到明确结论而不是凭经验说「感觉有点慢」。5.2 与 Prometheus 集成让 stress 指标进入监控大盘stress本身不输出 Prometheus 格式但我们可以用textfile collector做桥接。步骤如下创建/opt/prometheus/textfile/stress.prom内容为空修改上面的stability-check.sh在最后添加# 在脚本末尾追加 Prometheus 指标 { echo # HELP stress_cpu_bogo_ops_per_second CPU throughput in bogo ops/sec echo # TYPE stress_cpu_bogo_ops_per_second gauge echo stress_cpu_bogo_ops_per_second $CURRENT_CPU echo # HELP stress_hdd_bogo_ops_per_second Disk IOPS in bogo ops/sec echo # TYPE stress_hdd_bogo_ops_per_second gauge echo stress_hdd_bogo_ops_per_second $CURRENT_HDD } /opt/prometheus/textfile/stress.promPrometheus 配置中启用 textfile- job_name: stress static_configs: - targets: [localhost:9100] file_sd_configs: - files: - /opt/prometheus/textfile/*.prom这样stress_cpu_bogo_ops_per_second就会作为指标出现在 Grafana 中你可以设置告警规则rate(stress_cpu_bogo_ops_per_second[1h]) 0.95 * ignoring(instance) group_left() rate(stress_cpu_bogo_ops_per_second[1h] offset 24h)即「过去 1 小时均值比 24 小时前低 5% 以上」就触发告警。从那以后我每次给新机器做交付验收都强制走一遍stability-check.sh并把结果存档。不是为了证明机器多强而是留下一份可追溯的「健康基线」——当某天业务突然变慢我不用从头猜直接拉出三个月前的stress日志用diff一眼看出是 CPU 吞吐掉了还是磁盘 IOPS 跌了。这种确定性比任何「我觉得」「好像」都管用。希望帮到你。本文还有配套的精品资源点击获取