尧图网页设计 
简介本资源面向需要在无外网环境下完成 Linux 性能压测的运维与开发人员提供 CentOS 平台 stress 压力测试工具的离线安装方案。包内包含 stress-1.0.4 源码包及配套依赖并附带 sar 命令相关组件可解决内网服务器无法在线安装压测工具的痛点适合具备一定 Linux 基础、需要做 CPU、内存、IO 负载验证的工程师使用。资源共 43 个文件以 11 个 rpm 依赖包为主同时包含 configure、install-sh、depcomp 等编译脚本以及 readme、changelog、copying 等说明文档和源码文件压缩包整体约 46.66MB目录结构完整便于按需取用。目前已有 2585 人学习下载。通过该资源读者可快速在离线 CentOS 环境中完成 stress 的编译与部署结合 sar 命令采集系统负载数据为服务器稳定性测试、性能瓶颈排查提供可复用的工具链与排错参考。1. 内网 CentOS 上跑 stress为什么离线装比在线装更值得折腾机房里有台 CentOS 7.9 的机器网卡只通了内网yum 源指向一个早就没人维护的本地仓库yum install stress直接报No package stress available。这种场景下你要做压力测试验证 CPU 满载时的温度墙、验证某个服务在高负载下的响应退化手头却没有现成的包。在线装一条命令的事离线装就得把 RPM 依赖链摸清楚。stress 是个很轻的 POSIX 压力工具核心就干一件事fork 出一批 worker分别去啃 CPU、内存、IO、磁盘。它不像 stress-ng 那样功能铺得那么开但胜在体积小、依赖少、行为可预测特别适合塞进内网机器做基准压测。这篇笔记拆的是 CentOS 离线安装 stress 的完整路径从确认系统版本和架构到找对 RPM 包到处理依赖到跑起来验证再到几个我实际踩过的坑。适合手上有内网 CentOS 机器、需要做 CPU/内存压测但装不上包的运维和测试同学。2. 先搞清楚装什么stress 的包形态与 CentOS 版本对应关系2.1 stress 在 CentOS 生态里的三种来源CentOS 7 和 CentOS 8 Stream 的软件源策略不一样stress 的获取路径也不同。CentOS 7 时代stress 在 EPEL 源里包名就叫stress版本停在 1.0.4 左右。CentOS 8 之后stress 进了 AppStream 或者 EPEL但很多内网机器的 base 源根本没配 EPEL所以yum找不到。实际能拿到 RPM 的渠道有三类。第一类是 EPEL 官方仓库直接下stress-1.0.4-*.el7.x86_64.rpm这是最干净的。第二类是从一台已经装好 stress 的同版本机器上用yumdownloader或者直接去/var/cache/yum里把 RPM 抠出来。第三类是源码编译./configure make出来一个二进制但内网机器往往缺 gcc 和 make反而更麻烦。我一般优先走第一类因为 EPEL 的 RPM 签名可查依赖关系明确。第二类适合完全断网、连 EPEL 镜像都拷不进去的场景。第三类只在 RPM 实在找不到对应架构时才考虑。2.2 确认系统版本和架构别下错包离线装最大的翻车点就是包下错了。el7 的包装到 el8 上或者 x86_64 的包装到 aarch64 上rpm -ivh会直接甩你一脸package stress-1.0.4-1.el7.x86_64 is intended for a different architecture。所以动手前先把系统底细摸清楚。# 查看发行版和版本号 cat /etc/centos-release # 输出示例CentOS Linux release 7.9.2009 (Core) # 查看内核架构 uname -m # 输出 x86_64 或 aarch64 # 查看已配置的 yum 源确认有没有 epel yum repolist all | grep -i epelcat /etc/centos-release给出的是发行版本uname -m给出的是硬件架构。这两个信息决定了你要下哪个 RPM。比如CentOS Linux release 7.9.2009加x86_64对应的包就是stress-1.0.4-1.el7.x86_64.rpm。如果是 CentOS 8 Stream包名里的el7要换成el8。提示CentOS 7 已经停止维护EPEL 7 的镜像还在但部分镜像站可能已经归档。下包时优先选archive或vault路径别用已经 404 的常规路径。2.3 依赖链stress 到底依赖什么stress 的依赖非常干净。在 CentOS 7 上它只依赖libc.so.6和libm.so.6这两个是 glibc 提供的任何正常系统都有。用rpm -qpR可以查一个 RPM 的依赖# 假设你已经把 rpm 下到本地 rpm -qpR stress-1.0.4-1.el7.x86_64.rpm # 输出通常只有 # libc.so.6()(64bit) # libc.so.6(GLIBC_2.2.5)(64bit) # libm.so.6()(64bit) # rpmlib(CompressedFileNames) 3.0.4-1 # rpmlib(FileDigests) 4.6.0-1 # rpmlib(PayloadFilesHavePrefix) 4.0-1 # rtld(GNU_HASH)这些依赖在标准 CentOS 上全部满足所以 stress 的离线安装本质上就是「下一个包rpm 装上去」。真正会卡住的是rpmlib那几项它们要求 rpm 本身的版本够新。CentOS 7 自带的 rpm 是 4.11满足rpmlib(FileDigests) 4.6.0-1没问题。如果你在一台被裁剪过的容器镜像里装可能会缺rtld(GNU_HASH)那就得先补 glibc。3. 离线安装实操从下包到验证的完整命令链3.1 在一台有网的机器上把 RPM 拉下来最稳的做法是找一台和目标是同版本同架构的 CentOS配好 EPEL用yumdownloader把包和依赖一起下下来。yumdownloader来自yum-utils包如果那台机器也没有就先yum install -y yum-utils。# 在有网的 CentOS 7 上操作 # 安装 yum-utils提供 yumdownloader yum install -y yum-utils # 安装 epel-release启用 EPEL 源 yum install -y epel-release # 只下载 stress 的 rpm不安装--destdir 指定下载目录 yumdownloader --destdir/tmp/stress-offline stress # 查看下到了什么 ls -lh /tmp/stress-offline/ # 预期输出stress-1.0.4-1.el7.x86_64.rpmyumdownloader的--destdir参数指定下载目录--resolve参数会把依赖也一起下下来。stress 依赖少不加--resolve通常也够但加上更保险# 连同依赖一起下载 yumdownloader --destdir/tmp/stress-offline --resolve stress如果那台有网机器连 EPEL 都装不上就直接去 EPEL 的镜像站手动找。路径规律是https://mirrors.xxx/epel/7/x86_64/Packages/s/stress-1.0.4-1.el7.x86_64.rpm注意Packages/s/这个子目录stress 按首字母 s 归档。3.2 把 RPM 传到目标机器并校验内网传输一般走 scp 或者跳板机。传过去之后先别急着装用rpm -K校验包的完整性和签名。# 在目标 CentOS 机器上假设 rpm 已传到 /tmp cd /tmp # 校验 rpm 包的 md5/sha 和签名 rpm -K stress-1.0.4-1.el7.x86_64.rpm # 输出stress-1.0.4-1.el7.x86_64.rpm: rsa sha1 (md5) pgp md5 OK # 如果显示 NOT OK说明包在传输中损坏重新传rpm -K会检查包的 digest 和 GPG 签名。如果 EPEL 的 GPG key 没导入签名那项会显示(GPG) NOT OK (MISSING KEYS)但 digest 是 OK 的。这种情况下包本身没坏只是没法验证签名来源。内网环境如果信任传输通道可以继续装如果要求严格就先把 EPEL 的 GPG key 导进去# 导入 EPEL 7 的 GPG key如果机器上还没有 rpm --import https://mirrors.xxx/epel/RPM-GPG-KEY-EPEL-7 # 注意内网机器可能访问不了这个 URL需要提前把 key 文件拷进去 rpm --import /tmp/RPM-GPG-KEY-EPEL-73.3 用 rpm 安装并验证二进制可用校验通过后直接rpm -ivh安装。-i是安装-v是显示详情-h是显示进度条。# 安装 stress rpm -ivh stress-1.0.4-1.el7.x86_64.rpm # 输出 # Preparing... ################################# [100%] # Updating / installing... # 1:stress-1.0.4-1.el7 ################################# [100%] # 确认安装成功查包信息 rpm -qi stress # 输出包含 Name、Version、Release、Install Date 等 # 确认二进制位置 which stress # 输出/usr/bin/stress # 看版本和帮助 stress --version stress --helprpm -qi查的是已安装包的信息which stress确认二进制在 PATH 里。如果which找不到可能是/usr/bin不在 PATH或者包安装到了非标准路径正常不会。stress --version输出stress 1.0.4就说明装好了。注意如果之前装过旧版本rpm -ivh会报package stress-1.0.4-1.el7.x86_64 is already installed。要覆盖装用rpm -ivh --replacepkgs要升级用rpm -Uvh。3.4 跑一轮 CPU 和内存压测验证装完不跑等于没装。先用短时间、低并发试一下确认 stress 能正常 fork worker 并退出。# CPU 压测4 个 worker 啃 sqrt持续 10 秒 stress --cpu 4 --timeout 10s # 内存压测2 个 worker 各分配 256M持续 10 秒 stress --vm 2 --vm-bytes 256M --timeout 10s # 混合2 个 CPU worker 1 个内存 worker持续 30 秒 stress --cpu 2 --vm 1 --vm-bytes 512M --timeout 30s--cpu 4表示起 4 个 CPU 密集型 worker每个 worker 反复调用sqrt()。--vm 2起 2 个内存 worker--vm-bytes 256M指定每个 worker 分配并反复读写 256MB 内存。--timeout 10s让 stress 在 10 秒后自动退出不加这个参数它会一直跑到你 CtrlC。跑的时候另开一个终端看负载# 看 CPU 和内存实时占用 top -bn1 | head -20 # 或者用 uptime 看 1 分钟负载 uptime # 输出示例load average: 4.02, 1.15, 0.40 # 4 个 CPU worker 跑起来后1 分钟负载应该接近 4top -bn1是批处理模式跑一次适合脚本里抓快照。uptime的 load average 三个值分别是 1、5、15 分钟的平均负载。4 核机器跑--cpu 4负载接近 4 说明 worker 确实在啃 CPU。4. 避坑与排查离线装 stress 最容易翻车的五个点4.1 现象rpm 报依赖缺失但缺的是 glibc 的某个版本原因目标机器的 glibc 版本比 RPM 编译时依赖的版本低。比如包是在 glibc 2.17 上编的目标机器是 2.12rpm -ivh会报libc.so.6(GLIBC_2.14)(64bit) is needed。解决先查目标机器的 glibc 版本rpm -q glibc然后去找对应低版本 glibc 编译的 stress 包或者直接源码编译。源码编译时在目标机器上./configure make编出来的二进制天然匹配本机 glibc。如果目标机器没有 gcc就在同版本 glibc 的机器上编好再拷二进制过去。4.2 现象stress 跑起来后立刻退出没有任何输出原因--timeout参数写成了--timeout10或者--timeout 10不带单位。stress 的 timeout 接受s、m、h、d后缀不带后缀时默认按秒算但某些版本对格式敏感。解决统一写成--timeout 10s带单位最稳。另外检查是不是 worker 数量写成了 0--cpu 0等于不干活直接退。4.3 现象内存压测把机器跑 OOMssh 都连不上原因--vm-bytes设得太大比如在 4G 内存的机器上跑--vm 4 --vm-bytes 2G四个 worker 各要 2G直接触发 OOM killer可能把 sshd 都干掉。解决内存压测的--vm-bytes乘以--vm数量不要超过物理内存的 70%。4G 内存的机器--vm 2 --vm-bytes 1G是安全上限。跑之前先free -h看可用内存。如果要做极限压测加--vm-keep让 worker 保持内存不释放但更要控制总量。4.4 现象rpm -K 显示 GPG NOT OK不敢装原因EPEL 的 GPG 公钥没导入rpm 无法验证签名。解决把 EPEL 的 GPG key 文件拷到目标机器rpm --import导入后再校验。如果内网完全拿不到 key 文件至少确认rpm -K的 digest 部分是 OK 的说明包没损坏。签名验证是来源可信度问题digest 是完整性问题的两者分开看。4.5 现象装完之后 which stress 找不到原因/usr/bin不在当前用户的 PATH 里或者用了非标准 prefix 安装。解决rpm -ql stress列出包安装的所有文件找到二进制实际路径。如果是/usr/bin/stress但 which 找不到检查echo $PATH。如果是源码编译装到了/usr/local/bin确认那个路径在 PATH 里。临时用绝对路径/usr/bin/stress也能跑。5. 把 stress 用出基准价值参数组合与结果判读的几个技巧离线装好只是第一步真正让 stress 产生价值的是参数组合的设计和结果的判读。我一般会把压测分成三类场景来跑。第一类是 CPU 单核与多核对比。先stress --cpu 1 --timeout 60s记录uptime的 1 分钟负载和top里单核的%us。再stress --cpu $(nproc) --timeout 60s看多核是否线性扩展。如果 4 核跑满负载只有 3.2 而不是 4说明有核被其他进程占了或者 CPU 有降频。这个对比能帮你判断机器的实际算力上限。第二类是内存带宽与 swap 触发点。用--vm 1 --vm-bytes从 256M 逐步加到物理内存的 80%每档跑 30 秒同时用vmstat 1看si和soswap in/out。当si/so开始非零说明物理内存不够了开始吃 swap。这个拐点就是这台机器的内存安全水位。参数上--vm-bytes支持百分比写法比如--vm-bytes 80%但百分比是相对物理内存算的多 worker 时会叠加要小心。第三类是 IO 与 CPU 的相互干扰。stress --io 2 --cpu 2 --timeout 60s同时跑 IO 和 CPU worker用iostat -x 1看%util和await。如果 IO worker 把磁盘打满CPU worker 的完成速度会下降这能暴露存储瓶颈。stress 的--ioworker 是反复调用sync()对磁盘压力不算特别大真要压 IO 得用dd或fio但 stress 的--io适合做轻量干扰测试。判读结果时有个血泪经验别只看 load average。load 高不代表 CPU 忙可能是 IO 等待。一定要结合top的%us、%sy、%wa三个值一起看。%us高是用户态计算%sy高是系统调用%wa高是 IO 等待。stress 的 CPU worker 应该把%us拉高如果%wa也高说明有别的 IO 在抢。最后说一个参数细节--backoff。这个参数让 worker 在启动前等待指定微秒数默认是 0。在多 worker 场景下所有 worker 同时启动会造成瞬时负载尖峰。加--backoff 100000100 毫秒能让 worker 错峰启动压测曲线更平滑更适合观察稳态表现。这个参数在 stress 1.0.4 里就有但文档里提得少我是在一次压测曲线抖动得没法看的时候翻源码才注意到的。从那以后我每次做压测都强制先跑一轮 10 秒的低并发热身确认 stress 能正常退出、系统没有异常日志再上正式参数。这个习惯帮我挡掉过好几次「参数写错把机器跑挂」的事故。希望帮到你。本文还有配套的精品资源点击获取 内网 CentOS 离线安装 stress 压力测试工具完整指南
简介本资源面向需要在无外网环境下完成 Linux 性能压测的运维与开发人员提供 CentOS 平台 stress 压力测试工具的离线安装方案。包内包含 stress-1.0.4 源码包及配套依赖并附带 sar 命令相关组件可解决内网服务器无法在线安装压测工具的痛点适合具备一定 Linux 基础、需要做 CPU、内存、IO 负载验证的工程师使用。资源共 43 个文件以 11 个 rpm 依赖包为主同时包含 configure、install-sh、depcomp 等编译脚本以及 readme、changelog、copying 等说明文档和源码文件压缩包整体约 46.66MB目录结构完整便于按需取用。目前已有 2585 人学习下载。通过该资源读者可快速在离线 CentOS 环境中完成 stress 的编译与部署结合 sar 命令采集系统负载数据为服务器稳定性测试、性能瓶颈排查提供可复用的工具链与排错参考。1. 内网 CentOS 上跑 stress为什么离线装比在线装更值得折腾机房里有台 CentOS 7.9 的机器网卡只通了内网yum 源指向一个早就没人维护的本地仓库yum install stress直接报No package stress available。这种场景下你要做压力测试验证 CPU 满载时的温度墙、验证某个服务在高负载下的响应退化手头却没有现成的包。在线装一条命令的事离线装就得把 RPM 依赖链摸清楚。stress 是个很轻的 POSIX 压力工具核心就干一件事fork 出一批 worker分别去啃 CPU、内存、IO、磁盘。它不像 stress-ng 那样功能铺得那么开但胜在体积小、依赖少、行为可预测特别适合塞进内网机器做基准压测。这篇笔记拆的是 CentOS 离线安装 stress 的完整路径从确认系统版本和架构到找对 RPM 包到处理依赖到跑起来验证再到几个我实际踩过的坑。适合手上有内网 CentOS 机器、需要做 CPU/内存压测但装不上包的运维和测试同学。2. 先搞清楚装什么stress 的包形态与 CentOS 版本对应关系2.1 stress 在 CentOS 生态里的三种来源CentOS 7 和 CentOS 8 Stream 的软件源策略不一样stress 的获取路径也不同。CentOS 7 时代stress 在 EPEL 源里包名就叫stress版本停在 1.0.4 左右。CentOS 8 之后stress 进了 AppStream 或者 EPEL但很多内网机器的 base 源根本没配 EPEL所以yum找不到。实际能拿到 RPM 的渠道有三类。第一类是 EPEL 官方仓库直接下stress-1.0.4-*.el7.x86_64.rpm这是最干净的。第二类是从一台已经装好 stress 的同版本机器上用yumdownloader或者直接去/var/cache/yum里把 RPM 抠出来。第三类是源码编译./configure make出来一个二进制但内网机器往往缺 gcc 和 make反而更麻烦。我一般优先走第一类因为 EPEL 的 RPM 签名可查依赖关系明确。第二类适合完全断网、连 EPEL 镜像都拷不进去的场景。第三类只在 RPM 实在找不到对应架构时才考虑。2.2 确认系统版本和架构别下错包离线装最大的翻车点就是包下错了。el7 的包装到 el8 上或者 x86_64 的包装到 aarch64 上rpm -ivh会直接甩你一脸package stress-1.0.4-1.el7.x86_64 is intended for a different architecture。所以动手前先把系统底细摸清楚。# 查看发行版和版本号 cat /etc/centos-release # 输出示例CentOS Linux release 7.9.2009 (Core) # 查看内核架构 uname -m # 输出 x86_64 或 aarch64 # 查看已配置的 yum 源确认有没有 epel yum repolist all | grep -i epelcat /etc/centos-release给出的是发行版本uname -m给出的是硬件架构。这两个信息决定了你要下哪个 RPM。比如CentOS Linux release 7.9.2009加x86_64对应的包就是stress-1.0.4-1.el7.x86_64.rpm。如果是 CentOS 8 Stream包名里的el7要换成el8。提示CentOS 7 已经停止维护EPEL 7 的镜像还在但部分镜像站可能已经归档。下包时优先选archive或vault路径别用已经 404 的常规路径。2.3 依赖链stress 到底依赖什么stress 的依赖非常干净。在 CentOS 7 上它只依赖libc.so.6和libm.so.6这两个是 glibc 提供的任何正常系统都有。用rpm -qpR可以查一个 RPM 的依赖# 假设你已经把 rpm 下到本地 rpm -qpR stress-1.0.4-1.el7.x86_64.rpm # 输出通常只有 # libc.so.6()(64bit) # libc.so.6(GLIBC_2.2.5)(64bit) # libm.so.6()(64bit) # rpmlib(CompressedFileNames) 3.0.4-1 # rpmlib(FileDigests) 4.6.0-1 # rpmlib(PayloadFilesHavePrefix) 4.0-1 # rtld(GNU_HASH)这些依赖在标准 CentOS 上全部满足所以 stress 的离线安装本质上就是「下一个包rpm 装上去」。真正会卡住的是rpmlib那几项它们要求 rpm 本身的版本够新。CentOS 7 自带的 rpm 是 4.11满足rpmlib(FileDigests) 4.6.0-1没问题。如果你在一台被裁剪过的容器镜像里装可能会缺rtld(GNU_HASH)那就得先补 glibc。3. 离线安装实操从下包到验证的完整命令链3.1 在一台有网的机器上把 RPM 拉下来最稳的做法是找一台和目标是同版本同架构的 CentOS配好 EPEL用yumdownloader把包和依赖一起下下来。yumdownloader来自yum-utils包如果那台机器也没有就先yum install -y yum-utils。# 在有网的 CentOS 7 上操作 # 安装 yum-utils提供 yumdownloader yum install -y yum-utils # 安装 epel-release启用 EPEL 源 yum install -y epel-release # 只下载 stress 的 rpm不安装--destdir 指定下载目录 yumdownloader --destdir/tmp/stress-offline stress # 查看下到了什么 ls -lh /tmp/stress-offline/ # 预期输出stress-1.0.4-1.el7.x86_64.rpmyumdownloader的--destdir参数指定下载目录--resolve参数会把依赖也一起下下来。stress 依赖少不加--resolve通常也够但加上更保险# 连同依赖一起下载 yumdownloader --destdir/tmp/stress-offline --resolve stress如果那台有网机器连 EPEL 都装不上就直接去 EPEL 的镜像站手动找。路径规律是https://mirrors.xxx/epel/7/x86_64/Packages/s/stress-1.0.4-1.el7.x86_64.rpm注意Packages/s/这个子目录stress 按首字母 s 归档。3.2 把 RPM 传到目标机器并校验内网传输一般走 scp 或者跳板机。传过去之后先别急着装用rpm -K校验包的完整性和签名。# 在目标 CentOS 机器上假设 rpm 已传到 /tmp cd /tmp # 校验 rpm 包的 md5/sha 和签名 rpm -K stress-1.0.4-1.el7.x86_64.rpm # 输出stress-1.0.4-1.el7.x86_64.rpm: rsa sha1 (md5) pgp md5 OK # 如果显示 NOT OK说明包在传输中损坏重新传rpm -K会检查包的 digest 和 GPG 签名。如果 EPEL 的 GPG key 没导入签名那项会显示(GPG) NOT OK (MISSING KEYS)但 digest 是 OK 的。这种情况下包本身没坏只是没法验证签名来源。内网环境如果信任传输通道可以继续装如果要求严格就先把 EPEL 的 GPG key 导进去# 导入 EPEL 7 的 GPG key如果机器上还没有 rpm --import https://mirrors.xxx/epel/RPM-GPG-KEY-EPEL-7 # 注意内网机器可能访问不了这个 URL需要提前把 key 文件拷进去 rpm --import /tmp/RPM-GPG-KEY-EPEL-73.3 用 rpm 安装并验证二进制可用校验通过后直接rpm -ivh安装。-i是安装-v是显示详情-h是显示进度条。# 安装 stress rpm -ivh stress-1.0.4-1.el7.x86_64.rpm # 输出 # Preparing... ################################# [100%] # Updating / installing... # 1:stress-1.0.4-1.el7 ################################# [100%] # 确认安装成功查包信息 rpm -qi stress # 输出包含 Name、Version、Release、Install Date 等 # 确认二进制位置 which stress # 输出/usr/bin/stress # 看版本和帮助 stress --version stress --helprpm -qi查的是已安装包的信息which stress确认二进制在 PATH 里。如果which找不到可能是/usr/bin不在 PATH或者包安装到了非标准路径正常不会。stress --version输出stress 1.0.4就说明装好了。注意如果之前装过旧版本rpm -ivh会报package stress-1.0.4-1.el7.x86_64 is already installed。要覆盖装用rpm -ivh --replacepkgs要升级用rpm -Uvh。3.4 跑一轮 CPU 和内存压测验证装完不跑等于没装。先用短时间、低并发试一下确认 stress 能正常 fork worker 并退出。# CPU 压测4 个 worker 啃 sqrt持续 10 秒 stress --cpu 4 --timeout 10s # 内存压测2 个 worker 各分配 256M持续 10 秒 stress --vm 2 --vm-bytes 256M --timeout 10s # 混合2 个 CPU worker 1 个内存 worker持续 30 秒 stress --cpu 2 --vm 1 --vm-bytes 512M --timeout 30s--cpu 4表示起 4 个 CPU 密集型 worker每个 worker 反复调用sqrt()。--vm 2起 2 个内存 worker--vm-bytes 256M指定每个 worker 分配并反复读写 256MB 内存。--timeout 10s让 stress 在 10 秒后自动退出不加这个参数它会一直跑到你 CtrlC。跑的时候另开一个终端看负载# 看 CPU 和内存实时占用 top -bn1 | head -20 # 或者用 uptime 看 1 分钟负载 uptime # 输出示例load average: 4.02, 1.15, 0.40 # 4 个 CPU worker 跑起来后1 分钟负载应该接近 4top -bn1是批处理模式跑一次适合脚本里抓快照。uptime的 load average 三个值分别是 1、5、15 分钟的平均负载。4 核机器跑--cpu 4负载接近 4 说明 worker 确实在啃 CPU。4. 避坑与排查离线装 stress 最容易翻车的五个点4.1 现象rpm 报依赖缺失但缺的是 glibc 的某个版本原因目标机器的 glibc 版本比 RPM 编译时依赖的版本低。比如包是在 glibc 2.17 上编的目标机器是 2.12rpm -ivh会报libc.so.6(GLIBC_2.14)(64bit) is needed。解决先查目标机器的 glibc 版本rpm -q glibc然后去找对应低版本 glibc 编译的 stress 包或者直接源码编译。源码编译时在目标机器上./configure make编出来的二进制天然匹配本机 glibc。如果目标机器没有 gcc就在同版本 glibc 的机器上编好再拷二进制过去。4.2 现象stress 跑起来后立刻退出没有任何输出原因--timeout参数写成了--timeout10或者--timeout 10不带单位。stress 的 timeout 接受s、m、h、d后缀不带后缀时默认按秒算但某些版本对格式敏感。解决统一写成--timeout 10s带单位最稳。另外检查是不是 worker 数量写成了 0--cpu 0等于不干活直接退。4.3 现象内存压测把机器跑 OOMssh 都连不上原因--vm-bytes设得太大比如在 4G 内存的机器上跑--vm 4 --vm-bytes 2G四个 worker 各要 2G直接触发 OOM killer可能把 sshd 都干掉。解决内存压测的--vm-bytes乘以--vm数量不要超过物理内存的 70%。4G 内存的机器--vm 2 --vm-bytes 1G是安全上限。跑之前先free -h看可用内存。如果要做极限压测加--vm-keep让 worker 保持内存不释放但更要控制总量。4.4 现象rpm -K 显示 GPG NOT OK不敢装原因EPEL 的 GPG 公钥没导入rpm 无法验证签名。解决把 EPEL 的 GPG key 文件拷到目标机器rpm --import导入后再校验。如果内网完全拿不到 key 文件至少确认rpm -K的 digest 部分是 OK 的说明包没损坏。签名验证是来源可信度问题digest 是完整性问题的两者分开看。4.5 现象装完之后 which stress 找不到原因/usr/bin不在当前用户的 PATH 里或者用了非标准 prefix 安装。解决rpm -ql stress列出包安装的所有文件找到二进制实际路径。如果是/usr/bin/stress但 which 找不到检查echo $PATH。如果是源码编译装到了/usr/local/bin确认那个路径在 PATH 里。临时用绝对路径/usr/bin/stress也能跑。5. 把 stress 用出基准价值参数组合与结果判读的几个技巧离线装好只是第一步真正让 stress 产生价值的是参数组合的设计和结果的判读。我一般会把压测分成三类场景来跑。第一类是 CPU 单核与多核对比。先stress --cpu 1 --timeout 60s记录uptime的 1 分钟负载和top里单核的%us。再stress --cpu $(nproc) --timeout 60s看多核是否线性扩展。如果 4 核跑满负载只有 3.2 而不是 4说明有核被其他进程占了或者 CPU 有降频。这个对比能帮你判断机器的实际算力上限。第二类是内存带宽与 swap 触发点。用--vm 1 --vm-bytes从 256M 逐步加到物理内存的 80%每档跑 30 秒同时用vmstat 1看si和soswap in/out。当si/so开始非零说明物理内存不够了开始吃 swap。这个拐点就是这台机器的内存安全水位。参数上--vm-bytes支持百分比写法比如--vm-bytes 80%但百分比是相对物理内存算的多 worker 时会叠加要小心。第三类是 IO 与 CPU 的相互干扰。stress --io 2 --cpu 2 --timeout 60s同时跑 IO 和 CPU worker用iostat -x 1看%util和await。如果 IO worker 把磁盘打满CPU worker 的完成速度会下降这能暴露存储瓶颈。stress 的--ioworker 是反复调用sync()对磁盘压力不算特别大真要压 IO 得用dd或fio但 stress 的--io适合做轻量干扰测试。判读结果时有个血泪经验别只看 load average。load 高不代表 CPU 忙可能是 IO 等待。一定要结合top的%us、%sy、%wa三个值一起看。%us高是用户态计算%sy高是系统调用%wa高是 IO 等待。stress 的 CPU worker 应该把%us拉高如果%wa也高说明有别的 IO 在抢。最后说一个参数细节--backoff。这个参数让 worker 在启动前等待指定微秒数默认是 0。在多 worker 场景下所有 worker 同时启动会造成瞬时负载尖峰。加--backoff 100000100 毫秒能让 worker 错峰启动压测曲线更平滑更适合观察稳态表现。这个参数在 stress 1.0.4 里就有但文档里提得少我是在一次压测曲线抖动得没法看的时候翻源码才注意到的。从那以后我每次做压测都强制先跑一轮 10 秒的低并发热身确认 stress 能正常退出、系统没有异常日志再上正式参数。这个习惯帮我挡掉过好几次「参数写错把机器跑挂」的事故。希望帮到你。本文还有配套的精品资源点击获取