简介面向CentOS/Linux运维与性能测试人员的离线压力测试工具包解决内网或未联网环境下难以通过yum安装stress的问题。包内含stress-1.0.4源码、gcc-g等11个rpm依赖包以及sar命令支持在离线环境快速完成编译安装并配合sar进行性能监控。资源共43个文件以rpm安装包、configure/Makefile.in等编译脚本和源文件为核心同时包含readme、changelog、texi等说明文档整体文件类型覆盖安装、编译、文档三类需求压缩包大小46.66MB结构清晰便于按需取用。已有2587人学习下载适合需要在CentOS离线环境搭建stress压测环境、或想了解stress源码编译方式的读者。通过这份资源可一次获得可安装的rpm包、完整源码与编译说明免去逐一下载依赖的麻烦并能结合sar命令对系统负载进行量化分析。1. 离线安装 stressCentOS 压测先迈过的第一道坎新服务器验收、线上机器出现 CPU 告警、数据库扩容前做容量摸底这些场景里linux 压力测试工具 stress 几乎绕不开。可生产网段常常与外网物理隔离yum 源不通装这个只有几十 KB 的老牌工具反而比真正跑压测更让人头疼。很多帖子默认你连着公网在无网机器上照抄就会翻车。这篇文章把 CentOS 离线安装 stress 的全过程拆开从 rpm 下载、离线拷包、参数压测到结果判读全程按一线可复现的顺序写。新手照着能装起来老手也能看到依赖边界和几个容易踩的坑。2. 为什么是 stress它到底是怎么把负载造出来的2.1 stress 的工作模型fork、计算循环与资源占用stress 这个名字非常直白它不检测硬件好坏只负责制造负载。主进程启动后会按参数 fork 出若干子进程每个子进程自己进入独立的死循环CPU 模式里每个 worker 反复计算平方根内存模式里每个 worker 反复 malloc、逐字节 touch、再 freeIO 模式里每个 worker 循环调用 sync() 系统调用磁盘模式里则是反复 write 和 unlink 文件。你在压测时看到 load average 快速拉高不是因为某个程序在跑大任务而是大量进程在空转消耗特定资源。这种“一个 worker 只干扰一种资源”的设计有两个好处。第一是可控你可以单独压 CPU也可以同时叠加 CPU 和内存两个维度形成混合场景互不干扰。第二是可组合对服务器验收来说最常听到的需求就是“这批机器 CPU 扛得住吗”“内存条有没有问题”“磁盘在压力下会不会 hang 住”stress 的四个 worker 维度恰好对应这三个问题。需要提前接受一件事stress 不输出检测结论。它跑完只告诉你运行了多久、有没有被信号打断。有人形容它像个负载黑匣子你往里扔参数它往外吐负载结果好坏全靠外部的监控工具去验证。这个特性决定了后文所有压测做法都必须搭配观测侧命令来用单独看 stress 的终端输出是得不出任何“硬件正常”结论的。2.2 对比 stress-ng 和自写脚本为什么选 stress选型时最常被问到“为什么不用 stress-ng”。stress-ng 是 stress 的增强版压测模式上百种从 CPU cache 到 socket、semaphore 都能精确压问题是 rpm 包大、依赖多离线环境安装成本很高。对大多数运维验收和告警排查stress 的 CPU、内存、磁盘四个维度已经覆盖八成以上场景。方案维度控制离线安装成本适用场景stressCPU/内存/IO/磁盘四类 worker一个几十 KB 的 rpm仅依赖基础库CentOS 隔离环境、服务器验收、负载模拟stress-ng上百种压测模式包较大、依赖较多离线搬运麻烦深度调优、内核与存储专项测试自写 shell 脚本只能粗粒度控制无额外包成本但难以量化临时制造负载不适合验收再看自写脚本这条路。用 for 循环配 md5sum 或 tar 也能把 CPU 打起来但内存占用、IO 排队很难按比例控制更不能干净地指定每个维度并行几个 worker。我见过有人在生产环境用几条后台命令模拟高负载CPU 占用是上去了内存占用完全失控把监控告警全部触发了一遍。所以在这种场景下我一般直接选 stress不折腾。选它还有两个工程理由。第一是参数简单stress --cpu N --vm N --hdd N --timeout T一行表达完所有组合第二是退出码可预期超时结束返回正常信号方便放进自动化脚本判断压测有没有被中断。从“够用、能离线、好控制”三个角度看stress 是 CentOS 离线压测场景里性价比最高的选择。3. 离线安装完整流程从下载 rpm 到验证装包3.1 在线机器上把 RPM 包拉下来离线安装的第一步产能是在一台能访问外网、系统版本与目标机一致的 CentOS 上先把 stress 的 rpm 下载下来而不是直接安装。这样做的好处是包文件可以反复拷贝不会污染在线机器环境。做法一用 yum 自带的 downloadonly 选项mkdir -p /tmp/stress_rpm yum install --downloadonly --downloaddir/tmp/stress_rpm stress -y--downloadonly表示只下载不安装--downloaddir指定包保存目录-y跳过交互确认。执行完查看目录里面应该有一个 stress 开头的 rpm 文件和它依赖的包。如果 yum 版本较老提示不识别--downloadonly说明缺插件此时改用做法二。做法二用 yumdownloader属于 yum-utils 工具集yum install -y yum-utils yumdownloader --resolve --destdir/tmp/stress_rpm stress--resolve是 yumdownloader 的核心参数表示解析依赖关系并把缺失的依赖一起下载。两个命令对比--downloadonly是 yum install 过程中的开关yumdownloader是独立工具输出更直观包文件按依赖顺序铺在目录里对后面离线导入更友好。我一般推荐先装 yum-utils然后固定用 yumdownloader。下载完在装包前用两条命令检查依赖ls -lh /tmp/stress_rpm/ rpm -qpR /tmp/stress_rpm/stress-1.0.4-16.el7.x86_64.rpmrpm -qpR查询未安装包的依赖列表。一般会看到libc.so.6、libm.so.6、/bin/sh这些基础库CentOS 6 到 9 都自带这些说明只需要拷一个软件包就能离线装。如果输出里出现 gcc 或 make 之类先停下来确认源是否匹配系统版本版本不匹配是离线机翻车的高发原因。3.2 传输进隔离区scp 与目录规划第二步是传输。离线机器如果开了 SSH直接用 scp 拷到目标目录scp /tmp/stress_rpm/*.rpm ops10.10.20.30:/home/ops/stress_rpm/如果内网做了物理隔离SSH 也不通常见做法是走内网文件中转或者 U 盘拷入。无论用哪种方式都建议保持 rpm 原文件名和目录结构不要改名压缩再传同名文件在后续rpm -ivh时更容易对齐依赖关系。传到离线机后再验证一遍包完整性和依赖cd /home/ops/stress_rpm rpm -K ./stress-1.0.4-16.el7.x86_64.rpm rpm -qpR ./stress-1.0.4-16.el7.x86_64.rpmrpm -K用 GPG 签名做完整性校验如果内网机器没有导入对应 GPG key会提示NOKEY此时重点看签名摘要部分的输出是否正常。接着再用-qpR复查依赖对照离线机上的/lib64、/bin确认这些库确实存在然后再进入安装步骤。3.3 安装、验证与卸载不要在无网机上硬敲 yum离线机上执行安装sudo rpm -ivh ./stress-1.0.4-16.el7.x86_64.rpm stress --version rpm -ql stress第一行装包并打印 verbose 输出第二行确认版本能跑出1.0.4之类版本号就说明装上了第三行列出 stress 安装的文件清单顺带确认二进制在/usr/bin/stress。如果离线机之前装过旧版本用rpm -Uvh代替-ivh做升级覆盖如果提示already installed加--replacepkgs重新安装一次。一个常见误区是在离线机上直接敲yum install stress然后看它报failed to download metadata以为系统网络坏了。其实根源是/etc/yum.repos.d/里指的公网源全部不可达yum 本身没问题。正确路径是把.repo文件全部移到备份目录再配置内网镜像源如果没有内网源就维持 rpm 离线安装不要再去碰 yum。卸载路径也顺手留着压测完成后清理用sudo rpm -e stress这条命令在不需要工具时移除 stress 二进制但不会删掉压测期间产生的日志和监控数据方便后续回溯。对临时测试机来说装完验完、压完卸载是一条干净的操作闭环。4. 压测命令实战把 CPU、内存、磁盘逐个压起来4.1 CPU 压测worker 数量与超线程的实际关系新到一台 16 核服务器验收时先看满载温度这是最常见的 CPU 压测场景。命令如下nproc stress --cpu 16 --timeout 600s --backoff 200nproc返回的是逻辑核数超线程也算一个核。--cpu 16让 stress 创建 16 个 worker每个 worker 死循环执行 sqrt() 运算把 16 个逻辑核几乎全部拉满。--timeout 600s表示压 10 分钟后自动退出--backoff 200表示每个 worker 启动前等待 200 微秒错开 fork 风暴避免一开始 IPC 瞬间拉满。如果你看到 CPU 统计里只有 8 个核在动多半是--cpu参数写少了或者进程被 taskset 绑了核先别怀疑 stress 坏了。压测期间另开一个终端做监控top -d 2 mpstat -P ALL 1top的 %Cpu 看整体水位mpstat -P ALL 1按核输出利用率能确认每个核都在 work。需要不断压时可以不写--timeout但生产机上建议还是带上避免测试完忘收工导致机器一直满载。4.2 内存压测压占用还是压带宽参数差别很大内存维度最容易翻车先看容量再动手free -g stress --vm 4 --vm-bytes 2048M --timeout 300s--vm 4表示 4 个内存 worker每个 worker 分配 2048MB总占用约 8GB。stress 的默认行为是分配内存后逐页写一遍再 free模拟的是 malloc/free 反复操作适合压内存带宽和页表操作。如果你想模拟“内存长期被占用”的场景需要加--vm-hangstress --vm 4 --vm-bytes 2048M --vm-hang 0 --timeout 300s--vm-hang 0表示分配后不释放一直挂到超时退出。这种模式对内存不足的机器很危险一旦总占用超过物理内存系统会陷入重度换页并触发 OOM killer可能直接卡死。我一般把总占用控制在物理内存的 80% 以内16G 内存的机器--vm 4 --vm-bytes 3G就是 12GB给内核和日志留出余量。要更贴近真实业务访问模式可以用--vm-stride控制每次 touch 的字节步长模拟稀疏访问。4.3 磁盘 IO 压测与混合负载最玄学的部分在排队时间磁盘压测有两种方式--hdd是写文件再删掉适合压文件系统--io是反复执行 sync()CPU 占用不高但一直在走内存到磁盘的刷写路径。常用命令stress --hdd 4 --hdd-bytes 2G --timeout 300s--hdd-bytes 2G表示每个 worker 每次写 2G 文件再 unlink4 个 worker 并行。在机械盘上这会让磁头剧烈抖动在 SSD 上则看控制器队列深度。此时观察侧命令是iostat -x 1 vmstat 1 10重点看%util和await。%util到 100% 但 await 很低说明 SSD 队列健康await 持续拉高到几百毫秒说明磁盘排队严重。压测本身的停顿不算问题你需要的正是这种“有压力”的表现。最后是混合负载模拟数据库节点或应用服务器的典型高占用stress --cpu 8 --vm 2 --vm-bytes 4096M --hdd 2 --timeout 600s参数组合含义8 个 CPU worker 满载、2 个内存 worker 共约 8GB、2 个磁盘 worker 同时写删文件。混合模式下监控优先看vmstat的wa和si/so这两个值一旦持续走高说明磁盘或内存换页已经成为瓶颈。注意不要一上来就把所有维度打满先单项压 30 秒确认单点没问题再叠加组合。5. 避坑指南离线安装与压测中的常见故障排查压测中的翻车分两类一类是离线安装环节的依赖问题另一类是压测参数设计不合理的资源问题。以下五条都来自实际环境里的血泪经验按现象、原因、解决顺序写。5.1 现象rpm 安装报缺少依赖yum 源又不可达原因多半是下载的 rpm 来自 el8 或 el9与当前系统 libc 版本不匹配也可能是包下载不完整。离线机上 yum 无法在线解析依赖报错信息又只显示missing dependency容易误导人以为是系统坏了。解决先在在线机上用yumdownloader --resolve把依赖全部拉下来放在同一目录离线机上用rpm -Uvh *.rpm一次性装。装之前记得rpm -qpR核对依赖列表。这类“缺依赖、漏包”的情况在 Linux 运维故障案例里很典型关键就是养成装包前查依赖的习惯。5.2 现象压测进行到一半系统卡死SSH 无法响应原因内存压测参数超出物理内存或者磁盘 IO 把根分区写满。--vm-hang 0模式下内存 worker 不释放一旦总量超限OOM killer 开始杀进程系统进入高换页状态控制台都响应不过来。解决压测前先执行free -m和df -h内存 worker 总量控制在物理内存的 70% 到 80%。远程压测时用nohup把 stress 放到后台日志写文件而不是占终端压完再看结果不要人一直盯着屏幕。5.3 现象CPU 压测时负载很高但利用率只有一半原因--cpu参数小于逻辑核数或者 worker 被 cgroup、taskset 限制在部分核上。在云主机和 QEMU 虚拟机里宿主机超售也会让负载出现波动看起来像只有一半核在 work。解决先lscpu确认 CPU(S) 总数再用mpstat -P ALL 1看每个核是否独立工作。如果是通过taskset -c方式启动的 shell解除绑核虚拟机里的抖动属于常见现象不适合直接判断硬件故障需要拉长时间观察趋势。5.4 现象stress 压完输出了成功信息但压测结论不知道怎么写原因stress 默认只回显运行时间和退出状态没有健康判定能力。它不生成任何错误记录所以“run successfully”只能证明负载产生了不能证明硬件正常。把这一点理解了结论就不会乱写。解决压测前后各跑一遍系统日志检查给结论做支撑dmesg | grep -iE mce|hardware error|memory error | head journalctl -k --since 30 minutes ago | grep -iE error|fail | head ipmitool sdr list 2/dev/null | grep -i temp只有监控侧无异常时才把结论写为“60 分钟满载下未发现异常”不要轻易写“硬件完好”。温度数据用 lm_sensors 或 ipmitool 获取留作验收记录。5.5 现象离线机上装好了但本地镜像源反复超时原因/etc/yum.repos.d/里保留了不可达的公网源yum 每次操作都会先尝试它们超时之后才轮到本地源导致操作极慢甚至直接报错。解决把不用的.repo文件统一移动到/etc/yum.repos.d/backup/目录下确认是否有内网镜像源有就写一个只包含内网 baseurl 的 repo。如果只是装 stress 一个软件直接rpm -ivh比调镜像源快得多不用纠结 yum 的问题。6. 把压测固化成脚本三次压测、一份日志、一条命令出报告6.1 一键压测脚本模板#!/bin/bash LOGFILE/tmp/stress_report_$(date %Y%m%d_%H%M).log CORES$(nproc) FREEMEM$(free -m | awk /Mem:/ {print $7}) VMBYTES$((FREEMEM * 80 / 100 / 2)) echo pressure start at $(date) $LOGFILE stress --cpu $CORES --vm 2 --vm-bytes ${VMBYTES}M --hdd 2 --timeout 30m PID$! i0 while kill -0 $PID 2/dev/null [ $i -lt 30 ]; do echo $(date %H:%M:%S) $(uptime) $LOGFILE i$((i1)) sleep 60 done wait $PID echo pressure end at $(date) $LOGFILE这个脚本用nproc自动取逻辑核数free的 available 内存取 80% 且分给两个 worker避免 OOM。每 60 秒记录一次 uptimestress 进程结束时循环自然退出最后wait收集退出码。跑完之后用tail和dmesg快速出结论tail -n 5 /tmp/stress_report_*.log dmesg | grep -iE mce|hardware error | head6.2 压测期间的实时观察要点脚本只是骨架判断还是要靠两个终端。我跑长压时固定开三个窗口一个跑上述脚本一个跑mpstat -P ALL 1另一个跑iostat -x 1三个窗口的日志都落到 /tmp 下压测结束后统一 grep。想让压测覆盖真实业务可以在 30 分钟内修改两次--vm-bytes观察系统在内存水位变化时 swap 的表现配合磁盘 io 的排队变化。新硬盘挂载或扩容之后也建议先跑一轮混合压测再投入生产比单纯 dd 测速更接近真实负载形态。从那以后我每次压测新接手的机器都强制走一遍“先 free/df 预检、再 rpm -K 校验包、压测中开 mpstatiostat 双窗口、结束后查 dmesg”这四步很少再遇到“压完了不知道怎么下结论”的局面。希望帮到你。本文还有配套的精品资源点击获取
