简介这是Linux平台上一款经典的压力测试工具stress的完整源码与文档包面向系统管理员、运维工程师和性能测试开发者可通过模拟CPU、内存的高负载场景检验服务器在多任务并发下的稳定性、散热表现与极限吞吐能力可用于服务器选型、超频验证、云主机压测等场景。资源包共收录32个文件压缩后约199KB核心为stress-1.0.1源码stress.c配套configure配置脚本、Makefile.am/in构建文件、Texinfo格式权威文档stress.texi及README、ChangeLog、INSTALL等说明材料既适合阅读源码理解压力测试实现原理也便于在本地直接编译安装。学习后可掌握stress如何用多线程执行无意义计算耗尽CPU、如何分配并持续读写内存以测试内存带宽与虚拟内存管理同时理解--cpu、--vm、--vm-bytes等参数组合的实际效果还可结合top、htop、vmstat、iostat等工具进行实时观测形成一套完整的系统压测与结果分析方法。已有1036人学习该资源尤其适合希望深入Linux底层性能机制并动手实践的中高级用户。1. 为什么用 stress 给 Linux 加压先搞懂它测的是什么当服务器在业务高峰时频繁卡顿或者刚上线的机器跑几天就重启第一反应往往是“去看监控”。但监控只能告诉你系统现在不行没法告诉你硬件和内核到底能扛多大压力。stress linux加压测试工具的价值就是让你在改配置、换硬件、调内核参数之前先把机器按需求压到极限用可控的方式暴露问题。它不是跑分工具不输出性能分数它的职责是制造高负载场景配合运维常用的监控命令判断这台 Linux 是否稳定。这篇文章适合刚接触系统压力测试的运维新手也适合想把手里的服务器压出真实能力的嵌入式 Linux 开发者。2. 安装与最小复现从 apt/yum 到跑通第一个 CPU 压力测试2.1 在 Debian/Ubuntu 和 CentOS/RHEL 上安装 stressstress 在主流 Linux 发行版仓库里都有属于“镜像安装完就能用”的轻量工具。Debian/Ubuntu 用 aptCentOS/RHEL 用 yum国产 Linux 里大多数也兼容这两类包管理。下面是两条常见安装命令# Debian / Ubuntu / Mint sudo apt update sudo apt install -y stress # CentOS / RHEL / Rocky Linux / Alinux sudo yum install -y stress安装完用stress --version或which stress检查。这里最容易踩的坑是CentOS 最小化安装后没有启用 EPEL 源直接yum install stress会提示No package stress available。常见的做法是先安装 EPELsudo yum install -y epel-release sudo yum install -y stress为什么优先用发行版自带包因为 stress 依赖很少自带包足够跑完所有参数没必要自己编译。如果你恰好在一台没有外网源的离线机器上常见做法是找一台同架构机器把stress的 rpm 或 deb 包下下来用dpkg -i或rpm -ivh装。我不建议在生产机上源码编译除非你确实需要高于仓库版本的新特性。2.2 第一条加压命令让 CPU 满载并观察负载安装完先跑一条最简单的命令压 CPU 60 秒。这里我用 4 个 worker你可以根据机器核心数调整stress --cpu 4 --timeout 60s--cpu 4会创建 4 个子进程每个进程不断执行类似平方根计算的数学运算把 CPU 跑满。--timeout 60s是安全阀到时间自动退出避免你忘了 CtrlC 导致机器长时间满载。执行后在另一个终端里用top观察正常会看到 4 个 stress 进程占满 CPU 核心系统 load average 快速爬升。比如 4 核机器负载会跑到 4 左右。这里要注意如果是在虚拟机或云主机上做测试逻辑 vCPU 数量可能不等于物理核心数stress 的 worker 是跑在逻辑 CPU 上的后面第 5 章会细说。2.3 确认压力是否真的生效top、uptime、mpstat 怎么配合压力测试最怕“你以为压了其实没压”。只开一个 top往往看不到全局。我通常会同时开三个视角top看每个 stress 进程的 CPU 占用和系统 load average。uptime看 1/5/15 分钟负载确认压力是否持续。mpstat -P ALL 1逐核心看占用率确认压力分布是否均匀。# 每 1 秒输出一次所有 CPU 核心的使用率 mpstat -P ALL 1如果只有某个核心 100%其他核心空闲说明 worker 数小于核心数压力集中在部分核心上。要模拟整机满载就要把 worker 数调到逻辑核心数。还有一个细节load average 不只看 CPU还包含不可中断睡眠的进程数。所以压磁盘时哪怕 CPU 占用不高负载也会走高这点第 4 章会专门讲。3. 加压测试的完整参数地图CPU、内存、磁盘、IO 怎么组合3.1 CPU 压力worker 数与超线程的关系CPU 压力是 stress 最常用的场景。--cpu N里的 N 表示 worker 数量每个 worker 是一个独立进程。命令如下stress --cpu $(nproc) --timeout 10s --verbose$(nproc)会取当前机器的逻辑处理器数量。比如一台 4 核 8 线程的机器nproc返回 8stress 就会创建 8 个 worker每个逻辑核心满载。这里有个容易误解的点超线程只是让一个物理核心同时处理两个逻辑线程stress 的 worker 计算密集型任务时两个线程会争抢同一个物理核心的执行单元所以如果目标是测试“每个物理核心峰值性能”一个物理核心跑一个 worker 更接近真实但如果是模拟高并发用户请求按逻辑核心数压更常见。--timeout 10s是强制结束时间--verbose会输出每个 worker 的启动和退出信息。跑完你会看到进程退出后CPU 占用立刻掉下来。如果发现--cpu 4跑出来的负载只有 3 左右先别急着怀疑工具去查一下是不是有系统服务在占用 cpu或者 cpufreq 的节能策略把频率压低了。3.2 内存压力malloc 与 touch 的区别为什么需要 --vm-bytes内存压力用--vm和--vm-bytes配合。下面这条命令创建 2 个内存 worker每个分配 512MB分配后保持 10 秒stress --vm 2 --vm-bytes 512M --vm-hang 10 --timeout 60s--vm N表示同时有 N 个 worker 在做内存分配--vm-bytes是每个 worker 分配的内存大小--vm-hang让 worker 在分配后睡眠 N 秒而不是立刻释放这样内存压力能持续一段时间。为什么强调--vm-bytesstress 的内存 worker 会先调用 malloc 分配内存然后遍历这块内存写入数据也就是把页面真正“touch”到物理内存里。如果不指定--vm-bytes默认每个 worker 只分配 256MB压不出什么效果。另一方面malloc 只是虚拟地址空间分配不 touch 时物理内存占用很低所以实际压的是物理内存必须让它写页。跑之前建议先看内存余量free -h如果--vm 2 --vm-bytes 8G加上系统本身占用已经超过物理内存系统就会进入 swap 跌宕甚至触发 OOM。这个翻车现场会在第 5 章详细讲。3.3 磁盘与 IO利用 stress 的 hdd 选项制造写风暴stress 的磁盘压力通过--hdd实现。下面命令创建 2 个磁盘 worker每个 worker 在同一目录下写 1GB 数据后删除持续 30 秒mkdir -p /tmp/stress_dir cd /tmp/stress_dir stress --hdd 2 --hdd-bytes 1G --timeout 30s--hdd N会启动 N 个 worker每个 worker 执行“写入临时文件 → 调用 fsync → 删除文件”的循环。--hdd-bytes控制单次写入的数据量。要注意stress 的 hdd worker 默认会在当前目录下创建临时文件如果当前目录在根分区或数据盘上高强度写会把磁盘带宽打满甚至影响其他业务。常见做法是专门建一个/tmp/stress_dir或挂载一个独立的测试分区避免把重要目录暴露给随机写。另外--io N是让 worker 执行 sync() 系统调用会产生高 iowait但实际数据写入量并不大。它的作用是制造“IO 等待态”让 load average 升高适合模拟大量进程等待磁盘的场景。组合使用时我一般把--hdd和--io分开一旦混在一起很难判断是同步风暴还是写数据造成的卡顿。3.4 组合参数模拟真实高负载场景的常用配方单资源压测能暴露“这个单一资源缺不缺”但很多 linux 运维故障案例是资源争抢导致的比如内存不够时 CPU iowait 升高磁盘变慢时负载飙升。这时用组合参数更有效。下面是一个 5 分钟综合配方stress --cpu 4 \ --vm 2 --vm-bytes 1G \ --hdd 1 --hdd-bytes 1G \ --timeout 300s --verbose这条命令同时压 CPU、内存和磁盘。每条参数的逻辑是--cpu 4占满 4 个逻辑核心--vm 2用两个 worker 各分配 1G 内存--hdd 1在后台做写文件循环。组合起来系统各资源相互影响比如磁盘慢会导致进程进入 D 状态负载升高从而暴露内核调度或 cgroup 限制的问题。一个常见误区是把--cpu 4放到 2 核机器上跑会让系统调度过载负载虚高压力测试结果不可比。我的经验是先在单资源模式下把每一项跑通记录基线数据再组合测试。组合测试里每一项的参数要比单资源测试保守一点比如内存用量只取可用内存的 50%否则还没到真正的业务峰值机器先被压死了。4. 把 stress 的结果读成系统健康报告从负载、响应时间到温度4.1 负载 vs CPU 占用别被 top 骗了压测时top 里 load average 数值最直观但也最容易误导人。load average 统计的是处于 R运行和 D不可中断睡眠状态的进程数。stress 的--hdd会让进程频繁进入 D 状态等待磁盘这时你看 CPU 占用很可能只有 20%但 load average 却一路飙升到十几。所以读完 top 后至少要用mpstat -P ALL 1确认 CPU 占用分布再用iostat或vmstat判断 D 状态是否来自磁盘。比如一条压测命令结束后load average 还停在高峰先别怀疑 stress去查是不是磁盘队列里还有大量写请求没落盘。另一个细节load average 的 1 分钟值是短期波动5 分钟和 15 分钟值才是长期趋势。压测时我会故意把--timeout设成 120 秒以上压完后观察 5 分钟负载回落曲线。如果 15 分钟值仍然高于压测前的两倍说明有残留进程或磁盘任务没有排空。4.2 内存压力对系统性能的影响swap 和 oom内存压力不是单纯看 free 剩余多少而是看 swap 和 oom 行为。压测时用 vmstat 观察 si/so 和 free 字段vmstat 1 30si和so表示从 swap 换入和换出的数据量。只要这两个值持续非零说明系统已经出现内存回收和换页这时候哪怕 free 显示还有几百 MB实际响应速度也会明显变慢因为 CPU 大量时间在等待换页。继续加大--vm-bytes内核的 OOM killer 会介入杀掉进程。可以从 dmesg 里看到具体被杀进程dmesg | grep -i oomOOM 不一定只杀 stress 的 worker如果系统服务进程撞上 OOM可能会被杀掉这就是压测把自己的业务压挂了常见原因。所以在生产环境跑内存压力前务必先看业务进程的 OOM 保护值/proc/pid/oom_score_adj不要让关键服务暴露在高风险下。4.3 结合监控工具用 vmstat、iostat、sar 记录压力过程只看瞬时状态不够压测需要留证据。我习惯把 vmstat、iostat、sar 同时跑起来并把输出落到文件里压测结束后再分析。示例vmstat 1 /tmp/vmstat.log 21 VMSTAT_PID$! iostat -x 1 /tmp/iostat.log 21 IOSTAT_PID$! stress --cpu 8 --vm 2 --vm-bytes 1G --timeout 120s kill $VMSTAT_PID $IOSTAT_PID说明vmstat 1每秒输出一次系统内存、CPU、swap 状态iostat -x 1每秒输出一次磁盘 util、await、svctm 等指标。stress 结束后通过比对日志里的时间戳能准确还原压力发起和释放的整个过程。如果机器装有 sar也可以直接用sar -u -r -d 1 /tmp/sar.log 21 sar 的-u是 CPU-r是内存-d是磁盘。用日志文件的好处是压测结束后可以反复查不用盯着终端。5. 避坑指南stress 使用中的 5 个常见翻车现场5.1 现象SSH 断开、系统假死原因--cpu的 worker 数超过逻辑核心数太多再加上--vm和--hdd的组合CPU 长时间满载系统软中断和网络处理跟不上SSH 连接就被操作系统“甩掉”了。解决先把所有参数减半再跑。比如 4 核机器用stress --cpu 4 --timeout 30s确认负载正常后再加其他参数。同时可以给 stress 进程设置较低优先级nice -n 10 stress --cpu 8 --timeout 60snice -n 10降低进程优先级即使压力很大SSH 和系统管理进程仍然能抢到 CPU。压测时最好额外留一个已经登录的本地 console别只依赖 SSH。5.2 现象内存测试卡死机器迟迟不响应原因--vm-bytes加得太大超过了物理内存与 swap 的可用空间系统不断换页最终 OOM killer 直接冻结进程或者把桌面/业务进程一起带走。解决压测前先free -h看可用内存把--vm-bytes乘以 worker 数控制在可用内存一半以内。例如 16GB 内存的机器跑 2 个 worker每个 worker 设 4GB 已经是极限压测初次尝试建议从 2GB 起步stress --vm 2 --vm-bytes 2G --timeout 60s如果想让压力更温和加上--vm-hang 5让内存 worker 保持分配后休息而不是持续做分配释放这样压力更平缓。5.3 现象磁盘测试写爆目录或者文件系统报错原因--hdd会在当前目录生成临时文件如果当前目录在数据盘上一只写到 fsync文件系统或者磁盘被写穿某些文件系统会报 I/O error。解决永远不要在生产目录下直接跑磁盘压力。先建一个独立目录或挂载测试分区并把单次写入量控制住mkdir -p /mnt/test_stress cd /mnt/test_stress stress --hdd 1 --hdd-bytes 1G --timeout 30s如果需要长时间压磁盘建议用--hdd-bytes 64M这样的小尺寸避免单次写满整个分区。压完以后第一时间检查临时文件是否清理干净如果 stress 中途被 kill临时文件可能残留。5.4 现象压测结果不可比同一台机器两次负载值差很多原因两次压测之间CPUFreq 调速器状态不同机器可能处于 powersave 节能模式或者温度过高触发了降频。解决压测前固定 CPU 频率。常见的做法是用 cpupower 把 CPU 调到 performance 模式cpupower frequency-set -g performance如果 cpupower 没装用发行版包管理安装linux-cpupower。另外记录环境温度散热不好的机器在压测后期频率会下降负载可能比刚启动时低这不算工具问题是散热问题。要让结果可对比最好同一环境、同一模式、同一持续时间。5.5 现象CtrlC 后负载不降stress 进程还在原因stress 的信号处理会把 SIGINT 发给所有 worker但如果你用了 shell 管道、nohup 或 systemd 启动子进程信号可能没传递到全部 worker残留的 worker 继续消耗 CPU。解决用--timeout让 stress 自己优雅退出而不是依赖 CtrlC。如果已经残留直接清理pkill -u root stress如果是你自己的用户跑的用pkill stress即可。压测完再执行uptime确认负载回落不要急着离开终端。6. 把 stress 用出工程价值脚本化、限时自动降载与真实负载模拟6.1 封装一个带安全阀的综合加压脚本单次命令只适合临时试验巡检、验收、比对硬件时要做成脚本。下面这个脚本用当前系统负载倒推出资源用量并固定压测时长#!/bin/bash set -e # 根据可用内存的 25% 计算每个 vm worker 的分配量 AVAIL_MB$(free -m | awk /Mem:/{print $7}) VM_WORKERS2 VM_BYTES$((AVAIL_MB * 1024 * 1024 / 4 / VM_WORKERS)) CORES$(nproc) echo CPU workers: $CORES echo Each VM worker: $((VM_BYTES / 1024 / 1024)) MB stress --cpu $CORES \ --vm $VM_WORKERS --vm-bytes $VM_BYTES \ --hdd 1 --hdd-bytes 512M \ --timeout 300s --verbose这个脚本先读环境再组合压测。AVAIL_MB取 free 的 available 字段然后除以 4 再除以 worker 数保证内存压力只占可用内存的 25%不会把机器压到 OOM。压测结束后配合dmesg | tail -50检查内核日志有没有硬件错误或 OOM 记录这是比纯看负载更硬核的验证方式。6.2 结合 systemd 跑定期巡检压完必须自动降载如果你要周期性检查机器是否还能扛住峰值负载不建议直接 cron 跑 stress而是写一个 systemd service启动后自动压测压测结束后强制退出并记录状态。下面是一个简化的 service 脚本思路在 ExecStart 里调用上面那个脚本但把--timeout设为 600s然后通过 systemd 的TimeoutStopSec60s防止进程挂死。核心原则就一条压测必须有限时、有退出路径、有日志否则就是在给自己埋雷。6.3 验证、核对、形成习惯压测不是跑完就结束。我习惯压测前后各记录一份lscpu、free -h、uptime和磁盘iostat压测结束后对比这两份数据。如果负载回落慢先查进程如果 dmesg 有硬件错误先换内存或磁盘再谈调优。这比盯着 top 的瞬时值有用得多。做运维这些年最大的教训是压力测试不是用来折磨机器的而是让你在真实故障来临之前提前找到系统的短板。希望帮到你。本文还有配套的精品资源点击获取 Linux压力测试工具详解：用stress模拟CPU、内存与磁盘高负载
简介这是Linux平台上一款经典的压力测试工具stress的完整源码与文档包面向系统管理员、运维工程师和性能测试开发者可通过模拟CPU、内存的高负载场景检验服务器在多任务并发下的稳定性、散热表现与极限吞吐能力可用于服务器选型、超频验证、云主机压测等场景。资源包共收录32个文件压缩后约199KB核心为stress-1.0.1源码stress.c配套configure配置脚本、Makefile.am/in构建文件、Texinfo格式权威文档stress.texi及README、ChangeLog、INSTALL等说明材料既适合阅读源码理解压力测试实现原理也便于在本地直接编译安装。学习后可掌握stress如何用多线程执行无意义计算耗尽CPU、如何分配并持续读写内存以测试内存带宽与虚拟内存管理同时理解--cpu、--vm、--vm-bytes等参数组合的实际效果还可结合top、htop、vmstat、iostat等工具进行实时观测形成一套完整的系统压测与结果分析方法。已有1036人学习该资源尤其适合希望深入Linux底层性能机制并动手实践的中高级用户。1. 为什么用 stress 给 Linux 加压先搞懂它测的是什么当服务器在业务高峰时频繁卡顿或者刚上线的机器跑几天就重启第一反应往往是“去看监控”。但监控只能告诉你系统现在不行没法告诉你硬件和内核到底能扛多大压力。stress linux加压测试工具的价值就是让你在改配置、换硬件、调内核参数之前先把机器按需求压到极限用可控的方式暴露问题。它不是跑分工具不输出性能分数它的职责是制造高负载场景配合运维常用的监控命令判断这台 Linux 是否稳定。这篇文章适合刚接触系统压力测试的运维新手也适合想把手里的服务器压出真实能力的嵌入式 Linux 开发者。2. 安装与最小复现从 apt/yum 到跑通第一个 CPU 压力测试2.1 在 Debian/Ubuntu 和 CentOS/RHEL 上安装 stressstress 在主流 Linux 发行版仓库里都有属于“镜像安装完就能用”的轻量工具。Debian/Ubuntu 用 aptCentOS/RHEL 用 yum国产 Linux 里大多数也兼容这两类包管理。下面是两条常见安装命令# Debian / Ubuntu / Mint sudo apt update sudo apt install -y stress # CentOS / RHEL / Rocky Linux / Alinux sudo yum install -y stress安装完用stress --version或which stress检查。这里最容易踩的坑是CentOS 最小化安装后没有启用 EPEL 源直接yum install stress会提示No package stress available。常见的做法是先安装 EPELsudo yum install -y epel-release sudo yum install -y stress为什么优先用发行版自带包因为 stress 依赖很少自带包足够跑完所有参数没必要自己编译。如果你恰好在一台没有外网源的离线机器上常见做法是找一台同架构机器把stress的 rpm 或 deb 包下下来用dpkg -i或rpm -ivh装。我不建议在生产机上源码编译除非你确实需要高于仓库版本的新特性。2.2 第一条加压命令让 CPU 满载并观察负载安装完先跑一条最简单的命令压 CPU 60 秒。这里我用 4 个 worker你可以根据机器核心数调整stress --cpu 4 --timeout 60s--cpu 4会创建 4 个子进程每个进程不断执行类似平方根计算的数学运算把 CPU 跑满。--timeout 60s是安全阀到时间自动退出避免你忘了 CtrlC 导致机器长时间满载。执行后在另一个终端里用top观察正常会看到 4 个 stress 进程占满 CPU 核心系统 load average 快速爬升。比如 4 核机器负载会跑到 4 左右。这里要注意如果是在虚拟机或云主机上做测试逻辑 vCPU 数量可能不等于物理核心数stress 的 worker 是跑在逻辑 CPU 上的后面第 5 章会细说。2.3 确认压力是否真的生效top、uptime、mpstat 怎么配合压力测试最怕“你以为压了其实没压”。只开一个 top往往看不到全局。我通常会同时开三个视角top看每个 stress 进程的 CPU 占用和系统 load average。uptime看 1/5/15 分钟负载确认压力是否持续。mpstat -P ALL 1逐核心看占用率确认压力分布是否均匀。# 每 1 秒输出一次所有 CPU 核心的使用率 mpstat -P ALL 1如果只有某个核心 100%其他核心空闲说明 worker 数小于核心数压力集中在部分核心上。要模拟整机满载就要把 worker 数调到逻辑核心数。还有一个细节load average 不只看 CPU还包含不可中断睡眠的进程数。所以压磁盘时哪怕 CPU 占用不高负载也会走高这点第 4 章会专门讲。3. 加压测试的完整参数地图CPU、内存、磁盘、IO 怎么组合3.1 CPU 压力worker 数与超线程的关系CPU 压力是 stress 最常用的场景。--cpu N里的 N 表示 worker 数量每个 worker 是一个独立进程。命令如下stress --cpu $(nproc) --timeout 10s --verbose$(nproc)会取当前机器的逻辑处理器数量。比如一台 4 核 8 线程的机器nproc返回 8stress 就会创建 8 个 worker每个逻辑核心满载。这里有个容易误解的点超线程只是让一个物理核心同时处理两个逻辑线程stress 的 worker 计算密集型任务时两个线程会争抢同一个物理核心的执行单元所以如果目标是测试“每个物理核心峰值性能”一个物理核心跑一个 worker 更接近真实但如果是模拟高并发用户请求按逻辑核心数压更常见。--timeout 10s是强制结束时间--verbose会输出每个 worker 的启动和退出信息。跑完你会看到进程退出后CPU 占用立刻掉下来。如果发现--cpu 4跑出来的负载只有 3 左右先别急着怀疑工具去查一下是不是有系统服务在占用 cpu或者 cpufreq 的节能策略把频率压低了。3.2 内存压力malloc 与 touch 的区别为什么需要 --vm-bytes内存压力用--vm和--vm-bytes配合。下面这条命令创建 2 个内存 worker每个分配 512MB分配后保持 10 秒stress --vm 2 --vm-bytes 512M --vm-hang 10 --timeout 60s--vm N表示同时有 N 个 worker 在做内存分配--vm-bytes是每个 worker 分配的内存大小--vm-hang让 worker 在分配后睡眠 N 秒而不是立刻释放这样内存压力能持续一段时间。为什么强调--vm-bytesstress 的内存 worker 会先调用 malloc 分配内存然后遍历这块内存写入数据也就是把页面真正“touch”到物理内存里。如果不指定--vm-bytes默认每个 worker 只分配 256MB压不出什么效果。另一方面malloc 只是虚拟地址空间分配不 touch 时物理内存占用很低所以实际压的是物理内存必须让它写页。跑之前建议先看内存余量free -h如果--vm 2 --vm-bytes 8G加上系统本身占用已经超过物理内存系统就会进入 swap 跌宕甚至触发 OOM。这个翻车现场会在第 5 章详细讲。3.3 磁盘与 IO利用 stress 的 hdd 选项制造写风暴stress 的磁盘压力通过--hdd实现。下面命令创建 2 个磁盘 worker每个 worker 在同一目录下写 1GB 数据后删除持续 30 秒mkdir -p /tmp/stress_dir cd /tmp/stress_dir stress --hdd 2 --hdd-bytes 1G --timeout 30s--hdd N会启动 N 个 worker每个 worker 执行“写入临时文件 → 调用 fsync → 删除文件”的循环。--hdd-bytes控制单次写入的数据量。要注意stress 的 hdd worker 默认会在当前目录下创建临时文件如果当前目录在根分区或数据盘上高强度写会把磁盘带宽打满甚至影响其他业务。常见做法是专门建一个/tmp/stress_dir或挂载一个独立的测试分区避免把重要目录暴露给随机写。另外--io N是让 worker 执行 sync() 系统调用会产生高 iowait但实际数据写入量并不大。它的作用是制造“IO 等待态”让 load average 升高适合模拟大量进程等待磁盘的场景。组合使用时我一般把--hdd和--io分开一旦混在一起很难判断是同步风暴还是写数据造成的卡顿。3.4 组合参数模拟真实高负载场景的常用配方单资源压测能暴露“这个单一资源缺不缺”但很多 linux 运维故障案例是资源争抢导致的比如内存不够时 CPU iowait 升高磁盘变慢时负载飙升。这时用组合参数更有效。下面是一个 5 分钟综合配方stress --cpu 4 \ --vm 2 --vm-bytes 1G \ --hdd 1 --hdd-bytes 1G \ --timeout 300s --verbose这条命令同时压 CPU、内存和磁盘。每条参数的逻辑是--cpu 4占满 4 个逻辑核心--vm 2用两个 worker 各分配 1G 内存--hdd 1在后台做写文件循环。组合起来系统各资源相互影响比如磁盘慢会导致进程进入 D 状态负载升高从而暴露内核调度或 cgroup 限制的问题。一个常见误区是把--cpu 4放到 2 核机器上跑会让系统调度过载负载虚高压力测试结果不可比。我的经验是先在单资源模式下把每一项跑通记录基线数据再组合测试。组合测试里每一项的参数要比单资源测试保守一点比如内存用量只取可用内存的 50%否则还没到真正的业务峰值机器先被压死了。4. 把 stress 的结果读成系统健康报告从负载、响应时间到温度4.1 负载 vs CPU 占用别被 top 骗了压测时top 里 load average 数值最直观但也最容易误导人。load average 统计的是处于 R运行和 D不可中断睡眠状态的进程数。stress 的--hdd会让进程频繁进入 D 状态等待磁盘这时你看 CPU 占用很可能只有 20%但 load average 却一路飙升到十几。所以读完 top 后至少要用mpstat -P ALL 1确认 CPU 占用分布再用iostat或vmstat判断 D 状态是否来自磁盘。比如一条压测命令结束后load average 还停在高峰先别怀疑 stress去查是不是磁盘队列里还有大量写请求没落盘。另一个细节load average 的 1 分钟值是短期波动5 分钟和 15 分钟值才是长期趋势。压测时我会故意把--timeout设成 120 秒以上压完后观察 5 分钟负载回落曲线。如果 15 分钟值仍然高于压测前的两倍说明有残留进程或磁盘任务没有排空。4.2 内存压力对系统性能的影响swap 和 oom内存压力不是单纯看 free 剩余多少而是看 swap 和 oom 行为。压测时用 vmstat 观察 si/so 和 free 字段vmstat 1 30si和so表示从 swap 换入和换出的数据量。只要这两个值持续非零说明系统已经出现内存回收和换页这时候哪怕 free 显示还有几百 MB实际响应速度也会明显变慢因为 CPU 大量时间在等待换页。继续加大--vm-bytes内核的 OOM killer 会介入杀掉进程。可以从 dmesg 里看到具体被杀进程dmesg | grep -i oomOOM 不一定只杀 stress 的 worker如果系统服务进程撞上 OOM可能会被杀掉这就是压测把自己的业务压挂了常见原因。所以在生产环境跑内存压力前务必先看业务进程的 OOM 保护值/proc/pid/oom_score_adj不要让关键服务暴露在高风险下。4.3 结合监控工具用 vmstat、iostat、sar 记录压力过程只看瞬时状态不够压测需要留证据。我习惯把 vmstat、iostat、sar 同时跑起来并把输出落到文件里压测结束后再分析。示例vmstat 1 /tmp/vmstat.log 21 VMSTAT_PID$! iostat -x 1 /tmp/iostat.log 21 IOSTAT_PID$! stress --cpu 8 --vm 2 --vm-bytes 1G --timeout 120s kill $VMSTAT_PID $IOSTAT_PID说明vmstat 1每秒输出一次系统内存、CPU、swap 状态iostat -x 1每秒输出一次磁盘 util、await、svctm 等指标。stress 结束后通过比对日志里的时间戳能准确还原压力发起和释放的整个过程。如果机器装有 sar也可以直接用sar -u -r -d 1 /tmp/sar.log 21 sar 的-u是 CPU-r是内存-d是磁盘。用日志文件的好处是压测结束后可以反复查不用盯着终端。5. 避坑指南stress 使用中的 5 个常见翻车现场5.1 现象SSH 断开、系统假死原因--cpu的 worker 数超过逻辑核心数太多再加上--vm和--hdd的组合CPU 长时间满载系统软中断和网络处理跟不上SSH 连接就被操作系统“甩掉”了。解决先把所有参数减半再跑。比如 4 核机器用stress --cpu 4 --timeout 30s确认负载正常后再加其他参数。同时可以给 stress 进程设置较低优先级nice -n 10 stress --cpu 8 --timeout 60snice -n 10降低进程优先级即使压力很大SSH 和系统管理进程仍然能抢到 CPU。压测时最好额外留一个已经登录的本地 console别只依赖 SSH。5.2 现象内存测试卡死机器迟迟不响应原因--vm-bytes加得太大超过了物理内存与 swap 的可用空间系统不断换页最终 OOM killer 直接冻结进程或者把桌面/业务进程一起带走。解决压测前先free -h看可用内存把--vm-bytes乘以 worker 数控制在可用内存一半以内。例如 16GB 内存的机器跑 2 个 worker每个 worker 设 4GB 已经是极限压测初次尝试建议从 2GB 起步stress --vm 2 --vm-bytes 2G --timeout 60s如果想让压力更温和加上--vm-hang 5让内存 worker 保持分配后休息而不是持续做分配释放这样压力更平缓。5.3 现象磁盘测试写爆目录或者文件系统报错原因--hdd会在当前目录生成临时文件如果当前目录在数据盘上一只写到 fsync文件系统或者磁盘被写穿某些文件系统会报 I/O error。解决永远不要在生产目录下直接跑磁盘压力。先建一个独立目录或挂载测试分区并把单次写入量控制住mkdir -p /mnt/test_stress cd /mnt/test_stress stress --hdd 1 --hdd-bytes 1G --timeout 30s如果需要长时间压磁盘建议用--hdd-bytes 64M这样的小尺寸避免单次写满整个分区。压完以后第一时间检查临时文件是否清理干净如果 stress 中途被 kill临时文件可能残留。5.4 现象压测结果不可比同一台机器两次负载值差很多原因两次压测之间CPUFreq 调速器状态不同机器可能处于 powersave 节能模式或者温度过高触发了降频。解决压测前固定 CPU 频率。常见的做法是用 cpupower 把 CPU 调到 performance 模式cpupower frequency-set -g performance如果 cpupower 没装用发行版包管理安装linux-cpupower。另外记录环境温度散热不好的机器在压测后期频率会下降负载可能比刚启动时低这不算工具问题是散热问题。要让结果可对比最好同一环境、同一模式、同一持续时间。5.5 现象CtrlC 后负载不降stress 进程还在原因stress 的信号处理会把 SIGINT 发给所有 worker但如果你用了 shell 管道、nohup 或 systemd 启动子进程信号可能没传递到全部 worker残留的 worker 继续消耗 CPU。解决用--timeout让 stress 自己优雅退出而不是依赖 CtrlC。如果已经残留直接清理pkill -u root stress如果是你自己的用户跑的用pkill stress即可。压测完再执行uptime确认负载回落不要急着离开终端。6. 把 stress 用出工程价值脚本化、限时自动降载与真实负载模拟6.1 封装一个带安全阀的综合加压脚本单次命令只适合临时试验巡检、验收、比对硬件时要做成脚本。下面这个脚本用当前系统负载倒推出资源用量并固定压测时长#!/bin/bash set -e # 根据可用内存的 25% 计算每个 vm worker 的分配量 AVAIL_MB$(free -m | awk /Mem:/{print $7}) VM_WORKERS2 VM_BYTES$((AVAIL_MB * 1024 * 1024 / 4 / VM_WORKERS)) CORES$(nproc) echo CPU workers: $CORES echo Each VM worker: $((VM_BYTES / 1024 / 1024)) MB stress --cpu $CORES \ --vm $VM_WORKERS --vm-bytes $VM_BYTES \ --hdd 1 --hdd-bytes 512M \ --timeout 300s --verbose这个脚本先读环境再组合压测。AVAIL_MB取 free 的 available 字段然后除以 4 再除以 worker 数保证内存压力只占可用内存的 25%不会把机器压到 OOM。压测结束后配合dmesg | tail -50检查内核日志有没有硬件错误或 OOM 记录这是比纯看负载更硬核的验证方式。6.2 结合 systemd 跑定期巡检压完必须自动降载如果你要周期性检查机器是否还能扛住峰值负载不建议直接 cron 跑 stress而是写一个 systemd service启动后自动压测压测结束后强制退出并记录状态。下面是一个简化的 service 脚本思路在 ExecStart 里调用上面那个脚本但把--timeout设为 600s然后通过 systemd 的TimeoutStopSec60s防止进程挂死。核心原则就一条压测必须有限时、有退出路径、有日志否则就是在给自己埋雷。6.3 验证、核对、形成习惯压测不是跑完就结束。我习惯压测前后各记录一份lscpu、free -h、uptime和磁盘iostat压测结束后对比这两份数据。如果负载回落慢先查进程如果 dmesg 有硬件错误先换内存或磁盘再谈调优。这比盯着 top 的瞬时值有用得多。做运维这些年最大的教训是压力测试不是用来折磨机器的而是让你在真实故障来临之前提前找到系统的短板。希望帮到你。本文还有配套的精品资源点击获取