拓冰网站定制 
简介stress 是 Linux 平台上一款经典的开源系统压力测试工具面向系统管理员、运维工程师及内核调优爱好者用于在 CPU、内存、进程与线程等维度模拟高负载评估系统极限性能与稳定性。本资源为 stress-1.0.1 源码包共 32 个文件压缩包约 199KB包含 C 源码 stress.c、configure 与 Makefile 系列构建脚本、texinfo 与 html 格式文档、README、INSTALL、ChangeLog、NEWS 及测试校验脚本等覆盖从编译安装到功能验证的完整链路。读者可据此自行编译部署通过命令行参数灵活控制压力强度并结合 top、vmstat 等工具观察资源占用定位系统瓶颈与不稳定因素。目前已有 3079 人学习下载适合希望深入理解压力测试原理、动手实践源码编译与系统调优的读者参考。1. 压测不是跑个命令就完事stress 到底能帮你验证什么线上 CPU 飙到 90% 但业务没挂内存缓慢泄漏三天后才 OOM磁盘 IO 一压就卡成幻灯片——这些问题在真实故障里出现之前你根本不知道系统的临界点在哪。stress就是干这个的一个轻量级 Linux 压力测试工具通过创建指定数量的 worker 进程对 CPU、内存、IO、磁盘施加可控负载帮你验证系统在高压力下的表现。它不模拟业务逻辑只做一件事——把资源吃满看系统怎么反应。适合谁用运维做上线前的容量验证、后端开发排查性能瓶颈、嵌入式 Linux 工程师验证目标板在满载下的稳定性。源码只有一个 C 文件加几个辅助文件编译出来几百 KB扔到任何 Linux 环境都能跑。但很多人第一次用就是stress --cpu 8然后盯着 top 看这跟没测一样。下面从源码编译到参数调优到结果判读一步步拆开讲。2. 从源码到可执行文件stress 编译与最小验证2.1 为什么建议从源码编译而不是直接 apt installapt install stress或yum install stress确实快但有两个问题一是发行版仓库里的版本可能偏旧部分参数行为有差异二是你拿不到源码就没法改 worker 的行为逻辑。比如你想让内存 worker 分配后不立刻释放、或者调整 IO 块的写入模式都得改源码重新编译。stress 的源码结构极简核心就是stress.c加上Makefile和几个头文件编译依赖只有 gcc 和 make。先确认编译环境# 检查 gcc 和 make 是否就绪 gcc --version make --version # Debian/Ubuntu 系如果没有 gcc sudo apt update sudo apt install -y gcc make # RHEL/CentOS 系 sudo yum install -y gcc make拿到源码包后解压进入目录直接make即可。编译过程通常几秒钟产物就是一个stress可执行文件。这里有个细节源码里默认的CFLAGS可能没开优化如果你要做精确的 CPU 压测建议手动加上-O2# 清理后带优化重新编译 make clean make CFLAGS-O2 -Wall逻辑说明-O2让编译器做指令级优化避免因为编译产物本身效率低导致 CPU 没吃满就以为压测到位了。-Wall打开所有警告源码里如果有类型转换的隐患能提前发现。编译完成后用./stress --version确认可执行文件正常。2.2 四个核心参数的含义与最小验证命令stress 的参数不多但每个都直接影响压测结果。先把最常用的四个搞清楚参数作用典型值注意事项--cpu N启动 N 个 CPU 密集型 worker等于或略大于核数超过核数会看到负载但利用率不满--vm N启动 N 个内存分配 worker2~4配合--vm-bytes控制单 worker 分配量--vm-bytes B每个 vm worker 分配和触碰的字节数256M / 1G默认 256M写太大直接触发 OOM--io N启动 N 个同步 IO worker2~4调 fsync()对磁盘写入压力明显--hdd N启动 N 个磁盘写 worker1~2比--io更狠会实际写文件--timeout TT 秒后自动停止60s / 300s不加就是一直跑必须手动 kill最小验证先看 CPU 压测能不能把核吃满。# 启动与 CPU 核数相同的 worker持续 30 秒 nproc ./stress --cpu $(nproc) --timeout 30s # 另开一个终端观察 top -bn1 | head -20逻辑说明$(nproc)动态获取核数避免手写数字在 8 核机器上只压 4 个。--timeout 30s让 stress 自己退出不用你记着去 kill。观察 top 时重点看%Cpu(s)行的us用户态是否接近 100%以及load average是否在 1 分钟内快速上升。如果 us 只有 50% 左右说明 worker 数不够或者被其他进程抢了。内存压测要更小心# 2 个 worker每个分配 512MB持续 60 秒 ./stress --vm 2 --vm-bytes 512M --timeout 60s # 监控内存和 swap 变化 free -h vmstat 1 10逻辑说明--vm-bytes 512M是每个 worker 的量2 个 worker 就是 1GB。stress 的内存 worker 会不断分配、写入、释放模拟内存抖动。vmstat里看si和soswap in/out如果这两个值持续非零说明物理内存不够开始用 swap 了这时候系统响应会明显变慢。生产环境做这个测试前务必确认 swap 策略和 OOM killer 的行为。3. 组合压测与结果判读把 CPU、内存、IO 串起来看3.1 混合负载场景的参数搭配单独压 CPU 或内存只能看到单一维度的表现真实故障往往是多资源同时吃紧。比如一个 Java 服务在高并发下既吃 CPU 又吃内存还频繁写日志导致 IO 升高。用 stress 模拟这种场景# 混合压测4 CPU 2 内存 worker 2 IO worker持续 120 秒 ./stress --cpu 4 --vm 2 --vm-bytes 1G --io 2 --timeout 120s # 同时用 pidstat 分进程看资源占用 pidstat -u -r -d 1 5逻辑说明pidstat的-u看 CPU、-r看内存、-d看磁盘 IO每秒采样一次共 5 次。这样你能看到 stress 的各个 worker 进程分别吃了多少资源而不是只看系统总量。如果某个 worker 的 CPU 占用远低于预期可能是被 IO 等待阻塞了这时候要去看iowait的值。磁盘写入压测用--hdd更直接# 2 个磁盘写 worker每个写 1GB 临时文件 ./stress --hdd 2 --hdd-bytes 1G --timeout 60s # 观察磁盘写入速率和 IO 等待 iostat -x 1 5逻辑说明--hdd-bytes控制每个 worker 写入的临时文件大小stress 会在当前目录创建stress.*文件然后删除。iostat -x里重点看%util设备利用率和await平均等待时间。如果%util接近 100% 但await不高说明磁盘带宽被吃满但延迟还行如果await飙升到几十毫秒说明磁盘已经是瓶颈了。3.2 压测结果怎么读别只看 load average很多人压测完就看一眼uptime的 load average觉得数字高就是压力到位了。这是个典型的误判。load average 包含运行态和不可中断睡眠态D 状态的进程数IO 压测时大量进程处于 D 状态load 会很高但 CPU 可能很闲。正确的判读要分维度CPU 维度看top的ussy之和接近 100% 说明 CPU 吃满了。如果sy远高于us说明系统调用开销大可能是 IO 或网络导致的。内存维度看free的available列这个值持续下降到接近 0 就要警惕。IO 维度看iostat的%util和await前者反映设备忙不忙后者反映请求排队情况。还有一个容易被忽略的指标/proc/pressure/下的 PSIPressure Stall Information。较新的内核支持这个接口能直接告诉你 CPU、内存、IO 的争抢程度# 查看 CPU 压力 cat /proc/pressure/cpu # 查看 IO 压力 cat /proc/pressure/io # 查看内存压力 cat /proc/pressure/memory逻辑说明some行表示至少有一个任务因为该资源而停顿的时间占比full行表示所有任务都停顿的时间占比。压测时如果full行的avg10超过 10%说明资源争抢已经很严重了。这个指标比 load average 精确得多建议纳入压测判读的标准流程。4. 避坑与排查stress 压测中最容易翻车的五个点4.1 内存 worker 把机器压到 OOM 后 SSH 断连现象执行stress --vm 4 --vm-bytes 2G后SSH 会话卡死重新连接提示超时只能重启机器。原因4 个 worker 各分配 2GB总共 8GB如果物理内存只有 4GB内核的 OOM killer 会开始杀进程。它可能杀掉 sshd 或你的 shell 进程导致无法登录。更糟的是如果 swap 也没配够系统会进入假死状态。解决压测前先算清楚总内存量--vm数量乘以--vm-bytes不要超过物理内存的 70%。生产环境务必加--timeout并且用nohup或screen跑避免终端断开后 stress 变成孤儿进程继续吃内存。如果已经卡死尝试通过带外管理口登录或者等 OOM killer 自己恢复。4.2 CPU worker 数量超过核数导致数据失真现象8 核机器上跑--cpu 16top 显示 CPU 利用率只有 60% 左右load average 却很高。原因16 个 worker 争抢 8 个核大量时间花在上下文切换上实际有效计算时间反而下降。sy值会明显升高因为内核在频繁调度。解决CPU 压测的 worker 数设为核数或核数加一即可。如果要测超线程场景先确认lscpu里的Thread(s) per core值。真正想压满 CPU 应该用计算密集型任务而不是靠堆进程数。4.3 IO 压测把根分区写满现象--hdd跑了一段时间后服务开始报 No space left on device检查发现根分区满了。原因stress 的 hdd worker 会在当前工作目录创建临时文件如果当前目录在根分区且--hdd-bytes设得太大文件还没删就把分区写满了。解决压测前cd到一个独立的数据盘或/tmp确认/tmp是 tmpfs 或独立分区并且--hdd-bytes不要超过可用空间的 50%。跑完后确认stress.*临时文件已被清理没有残留。4.4 容器内压测影响宿主机和其他容器现象在 Docker 容器里跑 stress宿主机上其他服务响应变慢甚至被监控告警。原因容器默认不限制资源stress 在容器里看到的 CPU 和内存是宿主机的压测负载会直接打到宿主机内核调度器上。解决容器内压测必须加 cgroup 限制。用docker run时加--cpus和--memory比如--cpus2 --memory1g。Kubernetes 环境要确保 Pod 的resources.limits已配置。压测前跟同宿主机的其他服务负责人打个招呼别在业务高峰期做。4.5 stress 进程残留导致系统持续高负载现象以为 stress 已经退出了但系统负载一直降不下来ps一看还有一堆stress进程在跑。原因--timeout只对主进程有效如果 worker 进程因为某些原因没有正常退出比如被信号中断后没清理干净就会变成孤儿进程继续运行。另外用CtrlC中断时stress 的主进程会尝试清理子进程但如果子进程处于 D 状态不可中断睡眠清理会失败。解决压测结束后用pgrep stress确认没有残留有的话pkill -9 stress强制清理。养成习惯每次压测完都跑一遍pgrep -a stress确认干净了再走。5. 进阶技巧用 stress 做基线对比和自动化验证压测的价值不在于单次跑出多高的数字而在于能对比不同配置下的表现差异。我一般会做两件事一是建立基线二是把压测脚本化。基线对比的做法在系统空载时跑一次标准压测记录关键指标然后调整一个变量比如内核参数、JVM 堆大小、磁盘调度算法再跑同样的压测对比指标变化。比如测试vm.swappiness对内存压力的影响# 基线默认 swappiness60 cat /proc/sys/vm/swappiness ./stress --vm 2 --vm-bytes 1G --timeout 60s vmstat 1 60 /tmp/baseline_vmstat.txt # 调整 swappiness10 后重测 sudo sysctl vm.swappiness10 ./stress --vm 2 --vm-bytes 1G --timeout 60s vmstat 1 60 /tmp/tuned_vmstat.txt # 对比 si/so 列 diff (awk {print $7,$8} /tmp/baseline_vmstat.txt) (awk {print $7,$8} /tmp/tuned_vmstat.txt)逻辑说明vmstat的第 7、8 列分别是siswap in和soswap out。如果调低 swappiness 后这两个值明显下降说明内存压力下系统更倾向于保留物理页而不是换出对延迟敏感的服务更友好。这种对比比单看一次压测结果有说服力得多。自动化验证可以写成一个简单的 shell 脚本每次上线前跑一遍#!/bin/bash # stress_check.sh - 上线前基线压测脚本 DURATION60 CPU_WORKERS$(nproc) VM_WORKERS2 VM_BYTES1G echo 开始 CPU 压测 ./stress --cpu $CPU_WORKERS --timeout ${DURATION}s echo CPU 压测结束检查 load average: uptime echo 开始内存压测 ./stress --vm $VM_WORKERS --vm-bytes $VM_BYTES --timeout ${DURATION}s echo 内存压测结束检查 swap 使用: free -h echo 清理残留进程 pgrep -a stress pkill -9 stress echo 完成逻辑说明脚本按 CPU、内存顺序依次压测每个阶段结束后打印关键指标。最后强制清理残留进程避免影响后续操作。这个脚本可以集成到 CI/CD 流程里每次部署前自动跑一遍对比历史数据判断是否有性能退化。还有一个实用技巧用stress配合perf做热点分析。压测时开另一个终端跑perf top能看到内核和用户态的热点函数。如果发现某个锁竞争激烈或者某个系统调用占比异常就能定位到具体的性能瓶颈。这比只看利用率数字深入得多。从那以后我每次做压测都强制走一遍流程先算资源上限、加 timeout、确认工作目录、跑完检查残留进程。希望帮到你。本文还有配套的精品资源点击获取 Linux stress 压力测试实战：从源码编译到混合负载与结果判读
简介stress 是 Linux 平台上一款经典的开源系统压力测试工具面向系统管理员、运维工程师及内核调优爱好者用于在 CPU、内存、进程与线程等维度模拟高负载评估系统极限性能与稳定性。本资源为 stress-1.0.1 源码包共 32 个文件压缩包约 199KB包含 C 源码 stress.c、configure 与 Makefile 系列构建脚本、texinfo 与 html 格式文档、README、INSTALL、ChangeLog、NEWS 及测试校验脚本等覆盖从编译安装到功能验证的完整链路。读者可据此自行编译部署通过命令行参数灵活控制压力强度并结合 top、vmstat 等工具观察资源占用定位系统瓶颈与不稳定因素。目前已有 3079 人学习下载适合希望深入理解压力测试原理、动手实践源码编译与系统调优的读者参考。1. 压测不是跑个命令就完事stress 到底能帮你验证什么线上 CPU 飙到 90% 但业务没挂内存缓慢泄漏三天后才 OOM磁盘 IO 一压就卡成幻灯片——这些问题在真实故障里出现之前你根本不知道系统的临界点在哪。stress就是干这个的一个轻量级 Linux 压力测试工具通过创建指定数量的 worker 进程对 CPU、内存、IO、磁盘施加可控负载帮你验证系统在高压力下的表现。它不模拟业务逻辑只做一件事——把资源吃满看系统怎么反应。适合谁用运维做上线前的容量验证、后端开发排查性能瓶颈、嵌入式 Linux 工程师验证目标板在满载下的稳定性。源码只有一个 C 文件加几个辅助文件编译出来几百 KB扔到任何 Linux 环境都能跑。但很多人第一次用就是stress --cpu 8然后盯着 top 看这跟没测一样。下面从源码编译到参数调优到结果判读一步步拆开讲。2. 从源码到可执行文件stress 编译与最小验证2.1 为什么建议从源码编译而不是直接 apt installapt install stress或yum install stress确实快但有两个问题一是发行版仓库里的版本可能偏旧部分参数行为有差异二是你拿不到源码就没法改 worker 的行为逻辑。比如你想让内存 worker 分配后不立刻释放、或者调整 IO 块的写入模式都得改源码重新编译。stress 的源码结构极简核心就是stress.c加上Makefile和几个头文件编译依赖只有 gcc 和 make。先确认编译环境# 检查 gcc 和 make 是否就绪 gcc --version make --version # Debian/Ubuntu 系如果没有 gcc sudo apt update sudo apt install -y gcc make # RHEL/CentOS 系 sudo yum install -y gcc make拿到源码包后解压进入目录直接make即可。编译过程通常几秒钟产物就是一个stress可执行文件。这里有个细节源码里默认的CFLAGS可能没开优化如果你要做精确的 CPU 压测建议手动加上-O2# 清理后带优化重新编译 make clean make CFLAGS-O2 -Wall逻辑说明-O2让编译器做指令级优化避免因为编译产物本身效率低导致 CPU 没吃满就以为压测到位了。-Wall打开所有警告源码里如果有类型转换的隐患能提前发现。编译完成后用./stress --version确认可执行文件正常。2.2 四个核心参数的含义与最小验证命令stress 的参数不多但每个都直接影响压测结果。先把最常用的四个搞清楚参数作用典型值注意事项--cpu N启动 N 个 CPU 密集型 worker等于或略大于核数超过核数会看到负载但利用率不满--vm N启动 N 个内存分配 worker2~4配合--vm-bytes控制单 worker 分配量--vm-bytes B每个 vm worker 分配和触碰的字节数256M / 1G默认 256M写太大直接触发 OOM--io N启动 N 个同步 IO worker2~4调 fsync()对磁盘写入压力明显--hdd N启动 N 个磁盘写 worker1~2比--io更狠会实际写文件--timeout TT 秒后自动停止60s / 300s不加就是一直跑必须手动 kill最小验证先看 CPU 压测能不能把核吃满。# 启动与 CPU 核数相同的 worker持续 30 秒 nproc ./stress --cpu $(nproc) --timeout 30s # 另开一个终端观察 top -bn1 | head -20逻辑说明$(nproc)动态获取核数避免手写数字在 8 核机器上只压 4 个。--timeout 30s让 stress 自己退出不用你记着去 kill。观察 top 时重点看%Cpu(s)行的us用户态是否接近 100%以及load average是否在 1 分钟内快速上升。如果 us 只有 50% 左右说明 worker 数不够或者被其他进程抢了。内存压测要更小心# 2 个 worker每个分配 512MB持续 60 秒 ./stress --vm 2 --vm-bytes 512M --timeout 60s # 监控内存和 swap 变化 free -h vmstat 1 10逻辑说明--vm-bytes 512M是每个 worker 的量2 个 worker 就是 1GB。stress 的内存 worker 会不断分配、写入、释放模拟内存抖动。vmstat里看si和soswap in/out如果这两个值持续非零说明物理内存不够开始用 swap 了这时候系统响应会明显变慢。生产环境做这个测试前务必确认 swap 策略和 OOM killer 的行为。3. 组合压测与结果判读把 CPU、内存、IO 串起来看3.1 混合负载场景的参数搭配单独压 CPU 或内存只能看到单一维度的表现真实故障往往是多资源同时吃紧。比如一个 Java 服务在高并发下既吃 CPU 又吃内存还频繁写日志导致 IO 升高。用 stress 模拟这种场景# 混合压测4 CPU 2 内存 worker 2 IO worker持续 120 秒 ./stress --cpu 4 --vm 2 --vm-bytes 1G --io 2 --timeout 120s # 同时用 pidstat 分进程看资源占用 pidstat -u -r -d 1 5逻辑说明pidstat的-u看 CPU、-r看内存、-d看磁盘 IO每秒采样一次共 5 次。这样你能看到 stress 的各个 worker 进程分别吃了多少资源而不是只看系统总量。如果某个 worker 的 CPU 占用远低于预期可能是被 IO 等待阻塞了这时候要去看iowait的值。磁盘写入压测用--hdd更直接# 2 个磁盘写 worker每个写 1GB 临时文件 ./stress --hdd 2 --hdd-bytes 1G --timeout 60s # 观察磁盘写入速率和 IO 等待 iostat -x 1 5逻辑说明--hdd-bytes控制每个 worker 写入的临时文件大小stress 会在当前目录创建stress.*文件然后删除。iostat -x里重点看%util设备利用率和await平均等待时间。如果%util接近 100% 但await不高说明磁盘带宽被吃满但延迟还行如果await飙升到几十毫秒说明磁盘已经是瓶颈了。3.2 压测结果怎么读别只看 load average很多人压测完就看一眼uptime的 load average觉得数字高就是压力到位了。这是个典型的误判。load average 包含运行态和不可中断睡眠态D 状态的进程数IO 压测时大量进程处于 D 状态load 会很高但 CPU 可能很闲。正确的判读要分维度CPU 维度看top的ussy之和接近 100% 说明 CPU 吃满了。如果sy远高于us说明系统调用开销大可能是 IO 或网络导致的。内存维度看free的available列这个值持续下降到接近 0 就要警惕。IO 维度看iostat的%util和await前者反映设备忙不忙后者反映请求排队情况。还有一个容易被忽略的指标/proc/pressure/下的 PSIPressure Stall Information。较新的内核支持这个接口能直接告诉你 CPU、内存、IO 的争抢程度# 查看 CPU 压力 cat /proc/pressure/cpu # 查看 IO 压力 cat /proc/pressure/io # 查看内存压力 cat /proc/pressure/memory逻辑说明some行表示至少有一个任务因为该资源而停顿的时间占比full行表示所有任务都停顿的时间占比。压测时如果full行的avg10超过 10%说明资源争抢已经很严重了。这个指标比 load average 精确得多建议纳入压测判读的标准流程。4. 避坑与排查stress 压测中最容易翻车的五个点4.1 内存 worker 把机器压到 OOM 后 SSH 断连现象执行stress --vm 4 --vm-bytes 2G后SSH 会话卡死重新连接提示超时只能重启机器。原因4 个 worker 各分配 2GB总共 8GB如果物理内存只有 4GB内核的 OOM killer 会开始杀进程。它可能杀掉 sshd 或你的 shell 进程导致无法登录。更糟的是如果 swap 也没配够系统会进入假死状态。解决压测前先算清楚总内存量--vm数量乘以--vm-bytes不要超过物理内存的 70%。生产环境务必加--timeout并且用nohup或screen跑避免终端断开后 stress 变成孤儿进程继续吃内存。如果已经卡死尝试通过带外管理口登录或者等 OOM killer 自己恢复。4.2 CPU worker 数量超过核数导致数据失真现象8 核机器上跑--cpu 16top 显示 CPU 利用率只有 60% 左右load average 却很高。原因16 个 worker 争抢 8 个核大量时间花在上下文切换上实际有效计算时间反而下降。sy值会明显升高因为内核在频繁调度。解决CPU 压测的 worker 数设为核数或核数加一即可。如果要测超线程场景先确认lscpu里的Thread(s) per core值。真正想压满 CPU 应该用计算密集型任务而不是靠堆进程数。4.3 IO 压测把根分区写满现象--hdd跑了一段时间后服务开始报 No space left on device检查发现根分区满了。原因stress 的 hdd worker 会在当前工作目录创建临时文件如果当前目录在根分区且--hdd-bytes设得太大文件还没删就把分区写满了。解决压测前cd到一个独立的数据盘或/tmp确认/tmp是 tmpfs 或独立分区并且--hdd-bytes不要超过可用空间的 50%。跑完后确认stress.*临时文件已被清理没有残留。4.4 容器内压测影响宿主机和其他容器现象在 Docker 容器里跑 stress宿主机上其他服务响应变慢甚至被监控告警。原因容器默认不限制资源stress 在容器里看到的 CPU 和内存是宿主机的压测负载会直接打到宿主机内核调度器上。解决容器内压测必须加 cgroup 限制。用docker run时加--cpus和--memory比如--cpus2 --memory1g。Kubernetes 环境要确保 Pod 的resources.limits已配置。压测前跟同宿主机的其他服务负责人打个招呼别在业务高峰期做。4.5 stress 进程残留导致系统持续高负载现象以为 stress 已经退出了但系统负载一直降不下来ps一看还有一堆stress进程在跑。原因--timeout只对主进程有效如果 worker 进程因为某些原因没有正常退出比如被信号中断后没清理干净就会变成孤儿进程继续运行。另外用CtrlC中断时stress 的主进程会尝试清理子进程但如果子进程处于 D 状态不可中断睡眠清理会失败。解决压测结束后用pgrep stress确认没有残留有的话pkill -9 stress强制清理。养成习惯每次压测完都跑一遍pgrep -a stress确认干净了再走。5. 进阶技巧用 stress 做基线对比和自动化验证压测的价值不在于单次跑出多高的数字而在于能对比不同配置下的表现差异。我一般会做两件事一是建立基线二是把压测脚本化。基线对比的做法在系统空载时跑一次标准压测记录关键指标然后调整一个变量比如内核参数、JVM 堆大小、磁盘调度算法再跑同样的压测对比指标变化。比如测试vm.swappiness对内存压力的影响# 基线默认 swappiness60 cat /proc/sys/vm/swappiness ./stress --vm 2 --vm-bytes 1G --timeout 60s vmstat 1 60 /tmp/baseline_vmstat.txt # 调整 swappiness10 后重测 sudo sysctl vm.swappiness10 ./stress --vm 2 --vm-bytes 1G --timeout 60s vmstat 1 60 /tmp/tuned_vmstat.txt # 对比 si/so 列 diff (awk {print $7,$8} /tmp/baseline_vmstat.txt) (awk {print $7,$8} /tmp/tuned_vmstat.txt)逻辑说明vmstat的第 7、8 列分别是siswap in和soswap out。如果调低 swappiness 后这两个值明显下降说明内存压力下系统更倾向于保留物理页而不是换出对延迟敏感的服务更友好。这种对比比单看一次压测结果有说服力得多。自动化验证可以写成一个简单的 shell 脚本每次上线前跑一遍#!/bin/bash # stress_check.sh - 上线前基线压测脚本 DURATION60 CPU_WORKERS$(nproc) VM_WORKERS2 VM_BYTES1G echo 开始 CPU 压测 ./stress --cpu $CPU_WORKERS --timeout ${DURATION}s echo CPU 压测结束检查 load average: uptime echo 开始内存压测 ./stress --vm $VM_WORKERS --vm-bytes $VM_BYTES --timeout ${DURATION}s echo 内存压测结束检查 swap 使用: free -h echo 清理残留进程 pgrep -a stress pkill -9 stress echo 完成逻辑说明脚本按 CPU、内存顺序依次压测每个阶段结束后打印关键指标。最后强制清理残留进程避免影响后续操作。这个脚本可以集成到 CI/CD 流程里每次部署前自动跑一遍对比历史数据判断是否有性能退化。还有一个实用技巧用stress配合perf做热点分析。压测时开另一个终端跑perf top能看到内核和用户态的热点函数。如果发现某个锁竞争激烈或者某个系统调用占比异常就能定位到具体的性能瓶颈。这比只看利用率数字深入得多。从那以后我每次做压测都强制走一遍流程先算资源上限、加 timeout、确认工作目录、跑完检查残留进程。希望帮到你。本文还有配套的精品资源点击获取