简介这是一份基于stress-1.0.1的Linux压力测试工具源码包面向系统管理员、运维研发与性能测试人员。它将CPU密集计算、内存频繁分配与释放、线程并发调度等常见高负载场景集中在一个命令行工具中方便快速评估服务器在极限条件下的稳定性与性能上限。压缩包体积仅199KB内部有32个文件覆盖C语言主程序、编译配置脚本、构建模板、说明文档等类型既可直接编译部署也便于阅读实现细节。平台显示已有3031人学习下载适合具备Linux基础并希望掌握压力测试方法的工程师。借助源码可复现多线程计算、内存压力、进程创建等测试场景调整参数后配合进程与内存监控工具观察资源消耗状况从而定位潜在瓶颈为容量规划、稳定性验证与性能调优提供可靠依据。 很多搞Linux运维的朋友都遇到过这种场景机器CPU突然飙到高位load average居高不下业务响应变慢老板让你去排查但你不清楚这台机器在真正压满负载的时候到底稳不稳。这时候你会特别需要一把能“一键制造高负载”的螺丝刀。linux压力测试工具stress就是这类工具里最容易上手的一个它不生产花哨的性能报告也不带图形界面唯一做的事就是把CPU、内存、磁盘、IO按照你想要的程度拉满然后让你在旁边观察系统会不会出问题。这篇文章我会从stress的定位、安装、参数拆解、实战压测、结果判读讲到我自己踩过的几个坑。无论你是做运维、搞开发还是正在准备Linux相关的面试都能从中找到可以直接抄走的操作。顺带说一句面试里经常问的“load average是怎么变高的”“如何模拟系统高负载”用stress现场演示一遍比背定义管用得多。1. 先搞清楚stress的定位造故障可以跑分别找它1.1 stress真正适合干的几件事很多人第一次接触stress默认把它当成一个“性能测试工具”其实这个理解有偏差。stress的本职工作是“制造负载”不是在既定负载下测出“分数”。它的典型用法是你已经知道机器在高负载下可能出问题于是手动把负载制造出来然后验证问题是否真的会出现。我常用的场景有三个。第一是服务器稳定性验证。新采购的物理机或者刚换过CPU、散热器的机器用stress把每个核都压满跑上半小时甚至几小时观察会不会死机、重启、CPU降频离谱。第二是监控告警阈值验证。公司监控平台配了“CPU使用率超过80%就告警”“内存使用率超过90%就告警”但配置了不触发等于白配。用stress把负载推到目标水位确认告警真的能发出来。第三是复现问题。开发环境里碰到高负载下服务超时、OOM、锁竞争等诡异问题先用stress把机器压到指定水位再调用被测服务问题在可控条件下复现调试效率会高很多。如果你需要的是“这台服务器每秒能处理多少请求”“数据库能跑到多少QPS”这类量化结果那stress不适合你得去找sysbench、fio或者其他业务层压测工具。1.2 stress和其他工具怎么选Linux压测工具非常多新手容易看花眼。这里先给出我的选型结论快速验证机器稳定性用stress需要模拟更复杂、更细粒度的压力场景用stress-ng需要定量基准数据用sysbench需要精细测磁盘用fio。工具定位特点适用场景stress负载制造参数简单进程模型清晰适合把CPU、内存、IO快速打满稳定性验证、告警验证、面试演示stress-ng负载制造增强版stressor种类接近300种支持更多压力场景模拟复杂资源争抢、压力场景复现sysbench基准测试可测CPU、内存、文件IO、数据库输出量化指标需要具体性能数字时fio磁盘专项支持多引擎、多IO模式参数精细存储性能基准、磁盘故障排查一句话总结stress是“把机器打满看会不会崩”sysbench和fio是“测出机器在满载时到底能跑多少”。两者目的不同别混用。2. 安装和参数拆解stress是怎么把负载拉满的2.1 各发行版的安装方式stress在主流Linux发行版里都有软件包安装起来没有门槛。Debian/Ubuntu系列直接apt-get update apt-get install -y stressCentOS/RHEL 7系列系统默认源里没有stress需要先装EPEL源yum install -y epel-release yum install -y stressCentOS/RHEL 8/9系列用dnfdnf install -y epel-release dnf install -y stressAlpine这种极简发行版也能装上apk add stress安装完之后可以验证一下版本顺便确认路径stress --version which stress如果生产环境出于安全原因不能连外网也可以提前下载好RPM包或者源码包离线安装。源码编译安装的通用步骤是这样wget https://downloads.realvnc.com/... # 这个链接已经过时了别用说个教训网上很多旧教程会让人去官网下tar.gz再configure、make、make install。对stress这种小工具来说源码编译不是不能用但既然EPEL源和apt源里都有现成包能yum/apt装就别自己编译少给自己惹麻烦。2.2 核心参数逐个拆解stress的参数设计很简单我直接列一张表后面实战部分还会再演示组合用法。参数作用备注-c N生成N个CPU压力进程每个进程不停做sqrt浮点运算想打满8核就写--cpu 8-m N生成N个内存压力进程不断malloc、memset、free需要配合--vm-bytes指定单进程内存-d N生成N个磁盘写进程不断write临时文件再unlink默认每次写1GB可用--hdd-bytes调整-i N生成N个IO进程不停调用sync()系统调用主要制造系统调用和IO等待负载-t N压测持续时间默认单位秒可加s、m、h、d例如-t 60s、-t 10m、-t 1h-v详细模式打印压测过程中的日志排查时建议加上-q安静模式尽量少输出后台长时间跑时可用--vm-bytes N每个内存压力进程分配的字节数默认256MB可写成1G、512M--vm-hang N内存分配后挂起N秒再释放制造持续内存占用比反复malloc更接近真实负载--vm-keep分配内存后不释放继续反复访问内存水位会一直保持高位--hdd-bytes N每个磁盘写进程每次写入的大小默认1GB可写成512M、2G理解参数的关键在于进程模型。stress每收到一个压力参数就会fork出对应数量的子进程每个子进程在循环里执行对应的压力动作。也就是说--cpu 8不是“多线程”而是“8个独立进程”。这对理解load average特别重要Linux调度器调度的是任务8个满负荷运行的进程在8核机器上正好把每个核的队列占满load average会稳定在8左右。3. 四种实战压测用法把机器压到极限再看出不出问题3.1 CPU压测验证散热、降频和内核稳定性CPU压测是最常见的用法命令异常简单stress --cpu 8 --timeout 300这行命令会在8核机器上生成8个CPU压力进程持续300秒。压测过程中建议另开一个终端用top实时观察top -d 1正常情况下top第一行的load average会慢慢爬到8左右CPU使用率那行按核数计算最高能到800%左右top显示的百分比在所有核上累加。同时所有进程的CPU占用会平均分配到压力进程上。为什么要用stress而不是直接跑一个死循环脚本因为stress生成的是独立进程退出时能自动回收不会因为脚本写错导致机器一直高负载。这在做稳定性验证时非常重要你可以明确控制“压多长时间”“压到什么水位”。CPU压测除了验证散热和供电还能用来观察降频。压测五分钟后再看一眼温度数据比如用watch -n 1 sensors有lm-sensors时如果温度超过90度且频率开始掉说明散热系统有问题。3.2 内存压测动手之前先算好内存预算内存压测是踩坑重灾区因为压过头了机器可能直接卡死。先看命令再说预算。stress --vm 4 --vm-bytes 1G --vm-hang 30 --timeout 120这条命令会生成4个内存压力进程每个进程分配1GB内存分配完之后挂起30秒再释放循环直到120秒结束。4个进程合计占4GB。很多人不理解为什么需要--vm-hang。如果只分配、写、释放内存水位是忽高忽低的很难模拟真实服务里那种“长期占着内存不放”的状态。加上--vm-hang之后内存会持续被占用更接近生产环境。内存预算怎么算我建议用free -h先看当前可用内存free -h看到类似这样的输出total used free shared buff/cache available Mem: 15Gi 2.1Gi 8.2Gi 123Mi 5.1Gi 12Gi注意看available这一列这是真正可以分配给程序的量。我的习惯是压测总量控制在available的70%到80%并至少预留1GB给系统本身和SSH进程。比如available是12GB那压测内存就设定在8到9GB左右可以用--vm 4 --vm-bytes 2G也可以--vm 8 --vm-bytes 1G。进程数量多不一定更好关键看单进程内存大小和总预算。3.3 磁盘和IO压测观察iowait和写盘速度磁盘压力用--hdd系列参数stress --hdd 2 --hdd-bytes 512M --timeout 120这会生成2个磁盘写进程每个进程不断创建临时文件、写入512MB数据、删除文件循环往复。压测时需要配合iostat观察磁盘状态iostat -x 1重点看%util和await列。%util接近100%说明磁盘已经处于饱和状态await数值越高说明IO等待越严重。如果压测过程中服务出现明显卡顿说明瓶颈确实在磁盘层。IO压测可以用--iostress --io 4 --timeout 60这个参数生成的是不断调用sync()系统调用的进程产生大量的系统调用和等待但不会真的写大量数据。它更适合用来制造“进程都在等IO”的假象观察调度器和负载变化。3.4 组合压测与后台运行生产环境里CPU、内存、磁盘往往同时承受压力所以有时需要组合压测stress --cpu 4 --io 2 --vm 2 --vm-bytes 512M --hdd 1 --hdd-bytes 256M --timeout 600这会在四核机器上同时制造4线程CPU压力、2个IO等待进程、2个内存压力进程和1个磁盘写进程比较接近真实业务的多维负载场景。这种压测方式适合做整体稳定性验收比如新机器上架跑一晚上。压测时间较长时建议用nohup放到后台避免关闭终端导致stress进程退出nohup stress --cpu 8 --timeout 21600 /tmp/stress_cpu.log 21 写入日志文件后可以随时用tail -f /tmp/stress_cpu.log查看输出。我自己更习惯用tmux开一个独立会话跑压测这样既能后台运行又能随时切回去看实时状态比nohup更灵活。4. 压测结果怎么读负载、内核报错、系统卡顿4.1 读负载三板斧uptime、top、mpstat压测开始之后不能只看stress进程有没有起来还得确认负载确实到了预期水位。最常用的三个命令组合是uptime top -d 1 mpstat -P ALL 1uptime输出最后的三个数字就是load average的1分钟、5分钟、15分钟平均值。比如用stress --cpu 2压双核机器1分钟load会稳定在2左右然后慢慢往5分钟、15分钟的值传导。top主要看CPU使用率总和和进程状态。注意top显示的CPU百分比是所有核累加的双核机器满负载显示200%八核显示800%别以为显示100%就是满了。mpstat -P ALL 1可以看每个核单独的使用率。如果发现负载没到预期比如8个核只有4个核忙检查一下是不是--cpu数量给少了或者系统里其他服务也占了CPU导致压力进程没拿到全部时间片。4.2 异常信号OOM、soft lockup、卡死现象压测的目的就是暴露问题所以结果判读不能只看“跑没跑完”。压测结束后我强烈建议看一下内核日志dmesg -T | tail -n 100重点搜索几个关键词Out of memory说明内存压测过程中有进程被OOM killer杀掉。如果被杀的是业务进程那说明内存水位控制不合理或者业务本身存在内存泄漏。soft lockup某个CPU长时间无法调度可能是驱动问题、内核问题也可能是硬件不稳定导致的长时间关中断。Hardware error、mce开头的报错这是硬件级错误通常和CPU、内存条、主板相关遇到这类日志基本可以判断硬件有问题光压测不能解决问题需要走售后检测。除了日志还要观察压测期间服务器是否“假死”。比如SSH敲命令明显延迟、系统负载远高于预期但CPU使用率却不高等都是系统资源耗尽或锁冲突的信号。我给出一个简单判读标准压测过程中负载水到预期水位、期间没有内核报错、压测完成后系统能快速恢复空闲、业务服务没有异常退出。满足这四条基本可以认为这台机器在对应负载下是稳定的。如果压测本身触发了一大堆报错那问题不是“stress用错了”而是机器本身就有隐患这反而正好暴露了压测的价值。5. 我的翻车记录与后续工具推荐5.1 内存压得太大SSH直接失联这是我最「经典」的一次翻车。有一台16GB内存的测试机当时available有12GB我想着“反正内存多多压一点”直接执行了stress --vm 8 --vm-bytes 2G --timeout 3008乘以2G等于16G直接超过物理内存。机器内存吃满之后开始疯狂使用swap磁盘IO被swap读写拖死SSH连接卡到几乎无法输入最后只能通过带外管理口强制重启。这次之后我的规则很明确压测内存总量必须控制在available的80%以内而且至少预留1GB给SSH、系统服务这些“不能死”的进程。宁可用--vm 4 --vm-bytes 1G分两批压也不要一次压到极限。在内存压测里留有余地不是胆小是保命。5.2 终端一关stress跟着“自杀”不熟悉Linux信号机制的同事常踩这个坑SSH登录到服务器前台执行stress然后直接关掉终端窗口过一会儿回来看压力测试已经没了。原因是终端关闭时shell会给它的子进程发送SIGHUP信号stress收到SIGHUP默认就退出了。解决办法很简单要么用nohup要么用tmuxtmux new -s stress_test stress --cpu 8 --timeout 3600在tmux会话里执行stress然后Ctrlb再按d分离会话之后任何时候都能用tmux attach -t stress_test回去查看。我个人强烈推荐tmux方案因为你可以实时回来观察压测状态而nohup只能靠看日志。记住长时间压测一定要让stress脱离终端会话这事关压测的有效性和完整性。5.3 容器里压测的穿透效应还有一次是帮同事排查测试环境负载异常结果发现是有人在容器里跑stress。在没有配置CPU限额的容器里stress的CPU压力会直接打到宿主机上影响宿主机上所有其他容器。一台8核宿主机上某个容器执行stress --cpu 8整个宿主机的load直接被拉高其他容器里的服务全都变慢。如果你确实需要在容器里验证资源隔离或者做容量规划先确认容器的CPU限额和内存限额比如用docker inspect看NanoCpus、Memory字段确认限制生效后再压测。否则你压的不是容器是整个宿主机。这个坑的本质是很多人默认容器和虚拟机一样“隔离”其实CPU、内存资源隔离完全依赖cgroup配置配置不到位就是互相影响。压测前务必确认资源边界。5.4 从stress到更专业的工具后续升级路线我用stress做了很多年稳定性验证整体感受是它适合“快速打满观察问题”但如果你想做得更专业建议往stress-ng过渡。stress-ng的升级点在于压力场景极其丰富除了CPU、内存、磁盘、IO还能模拟诸如上下文切换、页错误、信号风暴、socket通信等非常具体的压力场景。而且它支持指定压测线程数、随机压力模式还有--metrics-brief可以输出简单的压力统计。安装和stress一样简单apt-get install -y stress-ng # 或者 dnf install -y stress-ng典型用法stress-ng --cpu 8 --vm 4 --vm-bytes 1G --timeout 60s --metrics-brief如果要做量化基准测试sysbench是更好的选择。sysbench可以测CPU事件速率、内存分配速率、文件IO吞吐量甚至还能配合oltp脚本对MySQL做压力测试。它和stress不是同一类工具但使用场景有部分重叠取决于你想得到“会不会出问题”还是“每秒能跑多少”的答案。我的建议是机器稳定性快速验证用stress复杂压力模拟用stress-ng性能基准用sysbench磁盘专项用fio。根据问题类型选工具而不是所有场景都靠一个工具硬扛。至少对我个人来说stress是我日常用得最多的那个“小螺丝刀”但真遇到需要精细定位的场景时我不会只靠它走完全程。本文还有配套的精品资源点击获取