简介stress是Linux环境下常用的开源压力测试工具此资源为stress-1.0.1完整源码包面向系统管理员、运维工程师及内核调试人员用于评估服务器或嵌入式设备在CPU、内存、磁盘I/O等高负载场景下的稳定性与性能极限。压缩包共含32个文件约199KB涵盖stress.c主源码、configure构建脚本、Makefile.am/in自动编译配置、texinfo/texi文档以及INSTALL/README说明文件并包含AUTHORS、ChangeLog等工程元数据类型配置颇为完整。已有3072人学习下载适合希望从源码层面理解压力测试原理并自行定制工具的开发者。通过研读源码与构建配置读者可掌握stress的CPU线程、内存分配等压力生成机制为后续结合dd或fio开展磁盘I/O测试、优化系统性能打下坚实基础。1. linux压力测试工具stress先搞清楚它能压什么、不能压什么一台新到的服务器装完系统第一件事不是部署业务而是先跑一遍负载测试确认散热、供电和内存颗粒别在业务上线以后才暴雷。我常用的是linux压力测试工具stress它足够简单、足够老派源码就一个压缩包编译后塞进任何离网环境都能跑比那些动不动拉一堆依赖的压测框架实用得多。stress能造出的压力是纯消耗型的CPU吃满整数运算、内存反复malloc再脏写、IO进程不停调sync制造磁盘刷盘压力。它不是一个业务模拟器压不出“像真实流量”的效果但它能最快暴露硬件环境问题散热压不住、内存ECC报错、磁盘固件在持续写入下不稳定。适合系统级的稳定性验收、超频验证、虚拟机热迁移前的逃生演练以及搞内核调试时想快速制造一个高负载现场的场景。2. stress的工作原理与选型理由为什么不用sysbench、不用dd2.1 stress的三种压力模型cpu fork、内存resize、io专属进程stress没有复杂的IO框架它的模型很原始启动后fork出一批子进程每个子进程去执行一个死循环或者反复系统调用。CPU压力是每个worker进程内跑整数循环典型的源码片段是while (1) { do_something(); }在单核上就占满一个逻辑核内存压力是通过mmap申请一块区域然后不停写入和读取IO压力则是子进程反复执行sync()、seek()和write()让块设备持续产生写刷盘动作。这个设计的妙处在于stress不需要特权端口、不需要额外内核模块普通用户都能跑起来一旦环境里不允许root操作你依然能对用户态CPU和内存做出压力。缺点也明显它没法模拟连接数、网络包频率、延迟抖动这些业务指标所以我的习惯是“硬件底子用stress验证业务容量用wrkr和jmeter验证”二者不互相替代。2.2 关键参数与单位换算别把-M和-d搞混stress的命令行参数十几年没怎么变过最常用的是下面几个参数完整形式作用常见陷阱-c--cpu生成CPU worker进程数每个吃满一核别以为-c 4一定等于4核还要看其他进程-m--vm生成内存分配/释放子进程数子进程会循环resize不是一次性占满--vm-bytes--vm-bytes 128M每个vm子进程申请多少字节内存支持K/M/G后缀不支持百分比字符串-d--hdd生成磁盘写子进程数stress的-d对抗的是脏页刷盘不是磁盘吞吐-i--io生成IO同步子进程反复sync()对物理盘压力小对云盘虚拟化的中断路径压力大-t--timeout压测总时长单位秒不写就是无限跑记得配屏幕复用--vm-hang--vm-hang 5每次分配内存后挂起N秒再释放很影响峰值内存占用按需使用参数单位换算我踩过一次坑--vm-bytes 200M听起来很大但实际是每个vm子进程申请200M如果你写-m 8那峰值就是1.6G并不算多。要压满32G内存我一般用-m 16 --vm-bytes 2G因为每个子进程的开销还包括系统回收的时间。2.3 与sysbench、dd的实际选型差异很多人纠结为什么不用sysbench。sysbench确实也能做CPU内存IO压力但它的定位是“基准测试”会给出诸如events per second、latency平均值这类统计指标跑一次要预热和清理参数语义也更接近OLTP场景。stress的定位是“制造故障现场”它不统计任何指标就是制造过载让系统和硬件在过载下暴露问题。如果你是在验证散热器压不压得住或者测试cgroup限额是否生效stress更顺滑。dd是更下位的替代品它只适合顺序写测试没法同时造CPU和内存压力也没法控制并发数。stress却可以把CPU、内存、IO三种压力按任意比例组合进一次运行这个组合能力是dd完全不具备的。写内核模块测试的时候我喜欢先起stress -c 4 -m 2 -i 1 -t 60等系统进入高压状态再插入别的现象观察这种用法sysbench反而碍事。3. 从源码编译stressconfigure、make、install全流程3.1 获取源码tarball仓库与克隆校验stress的源码在官方git仓库和各类镜像站都留了历史副本。我一般先试tarball因为可以用sha256sum校验完整性比直接git clone多一道安全确认。wget https://example.org/stress-1.0.4.tar.gz echo a1b2c3d4e5f6... stress-1.0.4.tar.gz | sha256sum -c - tar -xzf stress-1.0.4.tar.gz cd stress-1.0.4这里sha256sum -c -是从标准输入读校验值第一个输出是OK说明文件完好。如果你在一个全是老操作系统的内网记得先确认wget支持https协议不支持就改用curl或者干脆从U盘拷进去。解压后先看README和configure.ac确认版本号、依赖项和编译环境要求大部分场景下只需要gcc和make。3.2 编译三步走静态链接彻底解决库依赖stress的编译流程是典型的autotools流程configure生成Makefilemake编译make install安装。但生产服务器上不建议直接install到/usr/local,我通常做静态编译然后自己管理版本。./configure CFLAGS-O2 -static --prefix/opt/stress make -j$(nproc) make installCFLAGS里加-static是为了生成全静态可执行文件这样压测时不会因为某台机器缺共享库而失败。--prefix指定安装路径把stress装到独立目录业务环境里不污染系统库。-j$(nproc)是让make并行编译编译速度会快很多但机器内存如果小于2G建议去掉否则make本身会被编译过程压死。编译完还有一个习惯动作用ldd验证动态依赖。file /opt/stress/bin/stress ldd /opt/stress/bin/stress # 如果是静态编译ldd会输出not a dynamic executable静态版statically linked就像一颗单独滚动的棋子拷贝到其它机器也能直接跑很适合临时挂载一个/bin目录然后chroot进去做现场检测。想要追溯编译参数也可以直接看Makefile里的CFLAGS别相信脑子里记的。3.3 安装后的smoke测试一条命令确认工具可用安装后先跑一个最小场景确认CPU worker能正常生成并退出。stress --cpu 2 --timeout 3 echo $?正常会看到两条类似stress: info: [12345] dispatching hogs: 2 cpu的信息然后3秒后进程自动结束。echo $?输出0说明退出码正常如果输出非0比如1或2那通常是fork失败或者参数解析错误这时就要检查系统进程上限和ulimit值。如果不想等3秒也可以直接timeout 2 stress --cpu 2验证控制进程是否能被外部超时信号结束。这一步非常重要因为后续跑长压测时你肯定要依赖timeout来做自动收尾如果这一步就翻车后面写脚本会很难看。4. 实战把stress用出花来——常用场景与参数组合4.1 CPU核数与负载校准让负载精确等于物理核心数首先要搞清楚物理机的逻辑核心数nproc输出的是可调用线程数而lscpu -p可以列出每个core对应关系。我习惯先写一行命令把CPU信息打出来再决定stress的-c参数。nproc lscpu | grep -E ^CPU\(s\)|Core|Socket uptime-c nproc的结果是为了让load average恰好落在n附近这样你可以通过uptime的load值快速判断压力是否真实作用于CPU。如果压测开始后load在n和n1之间波动说明CPU worker正好占满所有核心此时再看温度曲线才有意义。如果load远低于n基本是CPU频率被功耗墙限制或者有超线程开关没打开。另外一点-c给到物理核心数的一半比如8核16线程给-c 8这样压的是真物理核而不是逻辑线程。很多云主机超线程是共享的满线程跑压力会导致邻位虚拟机被打扰这是我的血泪经验。4.2 内存压力与swap联动控制峰值不触发OOM内存压测最关键的是控制峰值我一般配合free -h和--vm-bytes精确设置。free -m stress --vm 4 --vm-bytes 1500M --vm-hang 10 --timeout 120这里--vm-hang 10让每个vm子进程在分配到1500M内存后挂起10秒再释放这样能保持峰值内存占用持续一段时间避免反复malloc占不满。4个进程x1500M就是6G跑之前先确认空闲内存比6G大20%左右否则系统会瞬间进入swap风暴卡到连看监控都困难。如果压测目标是验证swap 容量那可以故意把--vm-bytes设置到物理内存的90%让系统被迫用swap。但要注意连续慢速swap会拖慢所有进程建议全程用脚本记录vmstat 1的输出事后分析swap si/so两列的波动而不是眼睁睁看着机器卡死。还有一种更细密的玩法是配合ulimit -v限制每个进程的虚拟内存上限然后压测stress自己会不会因为malloc失败而abort这可以验证应用层是否有捕获分配失败的能力。stress在此场景下挺好用因为它对分配失败的反应就是报错退出不会去掩盖问题。4.3 IO压力与磁盘瓶颈模拟别被“sync风暴”误导stress的IO模式不是常规的磁盘读写吞吐它的本质是让多个IO子进程不停向内核发起同步制造扇区调度压力。对这种模式我一般搭配-d和-i一起用。stress --io 4 --hdd 2 --hdd-bytes 2G --timeout 30这个组合在机械盘上表现很明显磁盘利用率会持续在90%上下系统负载升高但磁盘实际写入量并不大。原因在于--hdd-bytes 2G控制了每次写文件的最大字节数写完就关闭重来2G大小对于机械盘来说不是连续大流量而是一次又一次的创建、seek、写、sync。如果你要压的是顺序写吞吐还是老实点用dd if/dev/zero of/tmp/test bs1M count4096 convfdatasync这不是stress能替代的。但如果你的目标是压“中断路径”——比如云盘的高并发IO完成中断、NVMe多队列调度stress的IO模式反而更有用因为它不产生多少实际数据却能让设备中断量持续升高。我测过一些htop里看到si软中断飙升的场景大多数就是stress这样的小包同步请求打出来的。4.4 组合场景稳定版服务器的“过载演练”把CPU、内存、IO三种压力摆进同一个压测跑你会发现不同维度互相牵扯这是我最常用的一种组合场景。stress --cpu 16 --vm 8 --vm-bytes 2G --vm-hang 5 --io 4 --hdd 2 --hdd-bytes 1G --timeout 600这个组合下8个vm进程同时消耗16G内存16个cpu worker把线程池顶满IO子进程持续调sync整体系统会进入全负载状态。跑过十分钟以后再观察两个东西一是dmesg -T有没有出现硬件报错、温度超限、page allocation失败二是top里waI/O wait和%si软中断的占比如果wa持续高于20%要警觉磁盘或设备驱动有问题。过载演练还适合验证监控告警是否有效。我一般配合watch -n 1 cat /sys/class/thermal/thermal_zone*/temp看温度曲线以及用sar -u 1 60记录CPU利用率和中断数据。stress在这里的任务很简单就是稳定制造一个60%以上的高负载环境让其他检测工具得到可信的数据。5. stress避坑指南跑压力前的四个必看细节5.1 现象压测时系统卡死SSH掉线重置才能恢复原因多数是内存压力超过了物理内存swap的总和触发OOM killer而内核在杀进程前的大规模换页会让系统像冻结一样有时是--vm-bytes设置过大导致docker容器直接MemoryLimit打满容器内所有进程被杀。解决压测前先free -g和cat /sys/fs/cgroup/memory.max确认当前限额把--vm-bytes控制在可用内存的70%以内。跑长压测时加-t超时时间再用nohup和输出重定向这样即使断连进程还能继续压并把日志写下来压完后看日志而不是看当时是否掉线。5.2 现象stress -m 报“invalid number”或者内存增长缓慢原因stress的--vm-bytes不识别百分比写法比如--vm-bytes 90%会被当作非法字符串然后启动失败另一种情况是--vm-bytes 200M实际每个worker分配200M而你的worker数量太多导致系统没有足够内存分配给每个子进程mmap失败后子进程直接退出表现为内存增长缓慢。解决先计算free -m后手动换算字节值再启动为了让内存快速膨胀可以同时给--vm-hang 0或不带hang参数让worker分配完马上再次resize分配频率会高很多。如果内存增长仍慢用strace -e tracemmap -p pid看是否卡在某个mmap调用上。5.3 现象IO压测后业务磁盘分区变满文件被写坏原因stress的--hdd会在当前工作目录创建临时文件默认写在.如果正好开在业务数据盘根目录脏文件写满分区导致后续业务操作失败还有-i模式配合某些日志系统会产生大量小文件碎片极端情况下会挤爆inode。解决压测前创建一个独立目录比如/var/tmp/test_dir进入后再启动stress压测后清理所有临时文件并检查df -i防止inode耗尽。我一般会在压测脚本的末尾加一条find /var/tmp/test_dir -type f -delete再验证分区空间是否恢复到压测前的水平。5.4 现象压测结果无参考价值系统负载一直不高原因笔记本或是云主机上有电源管理策略CPU频率被限制在低档比如800MHz这时stress虽然占满了时间片但实际计算量很小温度也上不去还有可能是cgroup的cpu.max限制住了整个容器的CPU配额。解决压测前先确认CPU运行频率cat /proc/cpuinfo | grep MHz在高压时再观察一遍。如果是频率被锁用cpupower frequency-set -g performance固定最高频率然后重跑。对于容器压测先检查cat /sys/fs/cgroup/cpu.max看见“200000 100000”这种就代表配额砍半要么改配额要么只压一半核数否则负载值怎么都上不去。5.5 现象kill stress 之后系统仍然高负载目录里残留一堆stress进程原因stress启动时fork出来的子进程不会自动退出如果你只kill了主进程子进程会变成孤儿进程驻留在后台或者你用了timeout命令但timeout发的是SIGTERMstress主进程收到信号后没有同步信号给子进程造成残留。解决压测结束后用pkill -9 -f stress清理所有匹配进程再查ps aux | grep stress确认干净。更好的办法是启动前记录主进程PID结束的时候用kill -TERM -PID对整个进程组发信号这能保证子进程一起退出。从那以后我每次压测都会把PID写进日志结束循环时强制走一遍进程组清理这个习惯帮我少看了很多“幽灵进程”。6. 进阶用stress验证内核调度策略的一个小技巧这个小技巧可以帮你直观验证Linux CFS调度器的权重分配逻辑尤其适合刚接触内核调度概念的人。先用taskset把两个stress绑定到同一个物理核再分别用不同nice值启动观察谁能占到更多CPU时间。taskset -c 3 nice -n -20 stress --cpu 1 --timeout 30 taskset -c 3 nice -n 19 stress --cpu 1 --timeout 30 top -b -n 2 -d 2 | grep stress第一个命令是绑定到第3核用nice -20最高优先级掺入一个stress进程第二个命令用nice 19最低优先级再启动一个stress进程它们共用一个核CFS根据nice权重分配时间片。top里能明显看到nice -20的stress的CPU占用率稳定在99%左右而nice 19的stress几乎拿不到时间片占用率接近0。这个现象证明CFS的nice不是“让出多少”而是按权重比例硬性分配nice 19和nice -20之间权重相差接近700倍。如果我想量化得更精确会再用perf stat取两个进程的CPU周期数做对比。这个技巧对理解容器CPU绑定和QoS优先级也很有启发同样的原理也适用于cgroup的cpu.weight调优场景。以前我总以为nice只是建议看到这个对比数据才真正把调度权重模型刻进脑子里从那以后我每次压测都强制走一遍基线记录、PID管理和这组调度验证才算完整体验了一个压力测试工具的价值。希望帮到你。本文还有配套的精品资源点击获取