简介面向Linux运维与性能测试工程师这套资源用于CentOS系统下离线安装stress压力测试工具解决内网或无外网环境无法通过yum获取软件包的问题。资源包含stress-1.0.4源码及配套的gcc-g等rpm依赖并涉及sar命令相关组件可支撑CPU、内存、I/O等场景的压力测试与系统性能监控。包体方面共43个文件以11个rpm安装包为主同时包含configure、texi、c、m4等源码编译所需文件便于在有依赖缺失时自行编译安装。压缩包为gz格式整体大小约46.66MB结构紧凑便于传输与备份。当前已有2587人学习下载。离线场景下可直接利用rpm包安装依赖快速完成stress部署避免逐一手动解决依赖链结合sar命令可在压测过程中采集CPU、内存等指标形成完整测试闭环。适合需要在内网或生产环境旁路验证系统稳定性的技术人员参考。1. 离线安装 stress一台连不上外网的 CentOS怎么把压测工具补齐生产网段里有一台 CentOS 7.9安全策略锁了外网连 yum update 都跑不了但容量评估要定期做压力测试工具 stress 必须装进这台机器。很多人第一次干这事直接在离线上执行 yum install stress等来的不是安装成功而是 mirrors.aliyun.com 下 repodata/repomd.xml 的 [Errno -1] 超时。这个报错不是源坏了而是你在一个没有外网的环境里硬要去访问外网源。离线安装 stress本质是把安装包和依赖在能上网的机器上拉齐再完整搬进内网装完还要能稳定运行。这篇文章写给被内网环境和安全策略卡住的运维也写给第一次接触离线部署的 Linux 使用者先讲方案怎么选再给能直接复现的打包、搬运、安装命令最后把最容易翻车的几个坑挨个拆开。2. 离线安装前先定方案rpm 打包、本地 yum 源和编译安装怎么选离线安装最忌讳的是拿起命令就冲。先花十分钟想清楚三件事内网有几台机器、要装几个包、系统版本是什么。这三点直接决定后面用哪套方案。带外网的机器上能轻松执行 yum install但离线机器上每一条 yum 命令都会变成一次漫长的超时等待所以动手前做方案判断比盲目敲命令划算得多。2.1 先确认三件事系统版本、架构和当前是否已经装过不管选哪条路第一组命令永远是这四个cat /etc/redhat-release uname -m rpm -qa | grep stress ls /etc/yum.repos.d/第一条看系统大版本CentOS 7 和 CentOS 8 的 rpm 包不能混用拿错了后面会出现段错误或error while loading shared libraries。第二条看架构x86_64 的包不能装在 aarch64 上反之亦然。第三条确认机器上是否已经存在 stress如果以前有人装过你只需要想办法拿到同版本 rpm 或者直接重新装一遍。第四条看离线机器上的 yum 源配置如果 /etc/yum.repos.d/ 里还留着公网镜像源后面执行 yum 相关命令时必然卡在连接超时上。再补一条网络可用性判断在离线机器上执行curl -I --connect-timeout 3 http://mirrors.aliyun.com/centos/7/os/x86_64/repodata/repomd.xml这条命令的通与不通能立刻告诉你当前环境是不是真的有外网。如果提示Connection timed out或Could not resolve host就老老实实走离线流程如果意外通了那说明机器只是没有配置 DNS 或源直接修 yum 源可能更省事。注意这条 curl 在完全离线的机器上会卡住几秒才返回超时这是正常现象别以为系统假死。2.2 三种离线安装方案怎么选rpm 打包、本地 yum 源和源码编译我把从业者最常用的方案放在一张表里后面逐个展开方案操作成本适用场景最容易踩的坑yumdownloader/repotrack 打包依赖后 rpm 安装低单台或几台机器、单个工具、依赖少依赖漏装、版本不匹配本地 yum 源 createrepo 生成索引中多台机器、多个包、需要长期维护repodata 索引缺失、源切换错源码编译 configure make make install高系统过老没有对应 rpm、需要改编译参数工具链缺失、编译失败方案一是最常用的。stress 这个工具依赖非常少实际上只需要 glibc 和 libm 这些基础库rpm 包里声明的依赖通常只有/bin/sh和几个libc.so.6()符号。用 yumdownloader 带--resolve把依赖一起拉下来拷到离线机器上再用 rpm -ivh 或 yum localinstall 装完整个过程半小时内能结束。方案二适用于内网里有几十台机器的情况。把下载好的 rpm 放到一个目录装一个 createrepo 生成 repodata再写一个指向本地 file:// 路径的 repo 文件每台机器就能直接 yum install。这个方案的优势是后续再补其它工具时只要往目录里丢 rpm 包并重新 createrepo 一次即可。劣势是 createrepo 工具本身在离线机器上不一定有需要提前带到内网而且生成完索引后要记得把 repo 文件指向本地否则 yum 依然会去访问外网。方案三源码编译适合两种极端场景一是系统太老比如 CentOS 5 / 早期 CentOS 6公共源里已经没有匹配的 stress 版本二是你需要在编译时开启某些自定义参数。stress 是 C 语言写的单文件工具configure make make install 并不难但前提是离线机器上要有 gcc、make、autoconf 等工具链。如果系统连开发工具都缺这条路会变成工具链离线安装的连环坑反而不如方案一省心。2.3 用一张依赖清单把安装边界看清楚下载完 rpm 之后别急着打包。在打包前先用 rpm 的依赖查询命令确认一下 stress 到底需要什么rpm -qpR stress-*.rpm这条命令会打印出 stress 这个 rpm 包的Requires字段也就是安装时检查的依赖项。常见输出是/bin/sh libc.so.6()(64bit) libc.so.6(GLIBC_2.4)(64bit) libm.so.6()(64bit)这些符号全部来自 glibcCentOS 7 自带的 glibc 默认满足。这里要特别提醒如果你发现依赖里有版本更高的GLIBC_2.28之类的符号说明这个 stress 包是从 CentOS 8 或更新系统上打出来的强行装到 CentOS 7 上会有隐患不要用升级 glibc 的方式去解决那属于开了一个更大的坑。此时应该回到有网机器从 EPEL 7 源里重新下载匹配的 stress。依赖清单的意义在于让你知道安装边界在哪里。stress 不是像 mysql、postgresql 那样有一大堆依赖的工具所以离线打包的失败率很低真正让新手翻车的都是从错误源下载了错误版本。把这份清单记在心里后面安装报错时你就能快速判断到底是缺包还是版本不对。3. 在有网机器上把依赖包拉齐yumdownloader 和 repotrack 帮你打包方案一旦确定下一步就是找到一台有外网的、系统版本和架构与目标机一致的机器把 stress 及全部依赖下载成 rpm 文件。这一步做扎实后面离线安装基本不会出意外如果这里图省事只下了一个包后面补依赖就会变成噩梦。3.1 先让有网机器能下载 stress启用 EPEL 源stress 不在 CentOS 基础 base 源里而是在 EPELExtra Packages for Enterprise Linux源里。在有网机器上先执行yum install -y epel-release yum install -y yum-utilsyum-utils 提供 yumdownloader 和 repotrack 两个关键工具。yumdownloader 负责下载 rpmrepotrack 负责连依赖一起下载。EPEL 源启用后先用yum list stress确认一下能看到这个包再往下走。如果yum list报错多半是 EPEL 源没有真正启用检查 /etc/yum.repos.d/epel.repo 里 enabled 是否为 1。这里有一个最容易被忽略的前提有网机器的系统版本和架构必须和离线目标机一致。如果你只有一台 CentOS 8 的机器却要给 CentOS 7 的目标机打包下载出来的包是 el8 的装到 el7 上大概率会报依赖缺失或段错误。最保险的做法是找一台与目标机同样大版本、同样架构的机器专门用来拉包。如果实在找不到可以在下载时手动指定 el7 的 repo 路径但这要求你对 repo 结构足够熟不推荐新手尝试。3.2 用 yumdownloader --resolve 拉包用 repotrack 兜底创建一个干净的目录存放所有 rpmmkdir -p /opt/stress-rpm cd /opt/stress-rpm yumdownloader --resolve --destdir/opt/stress-rpm stress--resolve的作用是把 stress 的依赖一起下载到 destdir 指定的目录而不是只下 stress 本体。注意它解析依赖时只会从当前已启用的 yum 源里找如果某个依赖在当前源里缺失会直接报错退出。我遇到过一种情况有网机器配置的是内网私有源只同步了 base 目录没有同步 EPEL结果 yumdownloader 提示找不到 stress 或某个依赖。这时要么把 epel 源加进来要么换用 repotrack。repotrack 是更稳妥的选择它会跟踪依赖树并把所有被依赖的包全部下载repotrack -p /opt/stress-rpm stress-p指定输出目录。repotrack 拉包通常比 yumdownloader 更全尤其当某个依赖既有 libc 符号又有额外库时它能避免漏包。下载完成后看一下目录内容ls -l /opt/stress-rpm正常情况下你至少会看到 stress 的主 rpm 和一个 glibc 相关的包。如果能看到glibc-2.17-xxx.el7.x86_64.rpm之类的文件说明依赖解析成功了。3.3 打包前先做依赖复核rpm -qpR 与 ldd下载完别急着压缩先复核一遍。写一个简单的循环检查所有 rpm 的依赖里是否有当前文件集覆盖不了的内容cd /opt/stress-rpm for f in *.rpm; do echo $f rpm -qpR $f 2/dev/null | grep -E ^/ || true done这个循环会对目录里每个 rpm 打印它的绝对路径类依赖比如/bin/sh。如果一个 rpm 依赖了某个不在目录里的绝对路径你就要记下来判断目标机是否已有。至于libc.so.6()这种符号依赖不用管目标机只要有 glibc 就能满足。还有一个验证思路适合需要彻底搞清楚运行环境的情况在有网机器上临时解压 stress 的 rpm对解压出来的二进制执行 lddrpm -ivh --root/tmp/stress-test --nodeps stress-*.rpm ldd /tmp/stress-test/usr/bin/stressldd 会打印这个二进制实际链接的动态库路径比如 libc.so.6、libm.so.6。如果这些库在目标机的 /lib64 下都存在安装后就能跑起来。这种方式本质上是把黑匣子打开看一眼虽然步骤多一点但能有效避免「rpm 装上了但一运行就报段错误」的尴尬。3.4 压缩、校验与内网传输确认依赖完备后把整个目录压缩成一个 tar 包方便传输和保留cd /opt tar czf stress-rpm.tar.gz stress-rpm sha256sum stress-rpm.tar.gztar 用czf是因为要压缩sha256sum 生成校验值用来在目标机上验证文件完整性。传输方式按你内网的现有条件来常见做法是用 scp 走内网 IPscp stress-rpm.tar.gz root目标内网IP:/opt/如果内网禁止直接 scp只能通过跳板机或运维平台上传那就把 tar 包放到批准目录再拷贝。传输完成后在目标机上重新计算一次校验值cd /opt sha256sum stress-rpm.tar.gz两次输出的哈希值一致再开始解压安装。这一步看起来多余但遇到过因为网络丢包导致 rpm 包损坏、安装时出现rpm: not an rpm package的人都会把校验当成固定流程。血泪经验别省。4. 在离线 CentOS 机器上安装 stress两种安装命令与压测参数包已经带到目标机上了接下来是安装环节。这里最大的敌人不是 stress 本身而是离线机器上的 yum 源配置。如果你直接执行 yum 开头的一堆命令系统会尝试连接那些写死的外网源然后卡在超时上白白浪费时间。4.1 先处理 repo 源别让 yum 去等外网解压完后第一步是把/etc/yum.repos.d/下所有指向外网的 repo 文件移走cd /opt tar xzf stress-rpm.tar.gz cd /etc/yum.repos.d mkdir -p backup mv *.repo backup/ 2/dev/null ls /etc/yum.repos.d/移到 backup 目录是为了留后悔药万一后面还需要某个源配置可以随时恢复。清空之后yum 在执行任何操作时都不会尝试连接外网源。这里要留意mv 命令里2/dev/null会吞掉一个不重要的报错比如目录里没有 .repo 文件的情况。执行完最好ls看一眼确认目录里确实干净。有些环境中 yum 会把 CentOS-Media.repo 留下来这个源指向本地光驱不影响离线安装可以不管它。真正要禁用的是那些写有mirrorlist或baseurlhttp://的 repo 文件因为它们都是为联网设计的。4.2 用 rpm -ivh 安装先装依赖再装主包在离线机器上rpm -ivh是最直观的安装方式。先看目录里的文件cd /opt/stress-rpm ls -l *.rpm如果里面只有 stress 主包和两个依赖包直接安装rpm -ivh stress-*.rpm如果提示缺少依赖比如出现libc.so.6()(64bit) is needed by stress不要慌张。这说明目录里的依赖包不全按依赖顺序先装缺失的包再装主包rpm -ivh glibc-*.rpm rpm -ivh stress-*.rpm这里强调一句不要用--nodeps硬装。--nodeps会跳过依赖检查rpm 命令倒是成功了但运行 stress 时会因为找不到库而报错反而把问题拖到后面更难看。真正需要处理的是依赖缺失不是绕过依赖检查。rpm -ivh 与 rpm -Uvh 的区别也值得说清楚。-U是升级安装如果目标机已经有旧版 stress-Uvh会先卸载旧的再装新的-ivh遇到已安装的同版本包会报错。离线安装时我一般用-ivh因为目标机大概率没装过 stress用-Uvh反而可能在卸载旧包时触发额外检查。4.3 更省事的安装yum localinstall 自动解析本地依赖如果你不想手动排依赖顺序可以用 yum 的 localinstall 功能。先禁用所有外网源再让 yum 从本地 rpm 目录里自动建立依赖关系yum --disablerepo* localinstall -y /opt/stress-rpm/*.rpm--disablerepo*表示这次命令不使用任何已配置的源yum 只处理你显式给出的本地 rpm 文件。localinstall 的流程是先把这些 rpm 读入内存然后分析依赖关系自动确定安装顺序比手动 rpm -ivh 逐个敲命令更省心。不过 localinstall 也有一个绕不开前提离线机器上必须已经安装了 yum 基础工具。如果是 CentOS 7 这种自带 yum 的系统问题不大如果你处理的是一个被裁剪过的最小系统连 yum 都没有那就只能回到 rpm -ivh 手动装。还有一点需要注意--disablerepo*会让某些依赖了 repo 查询的插件报 warning只要最后能安装成功这些 warning 可以忽略。4.4 验证安装并做第一轮小规模压测安装完成后先跑一个最简单的验证stress --version stress -c 1 -t 10 uptime第一条打印版本证明二进制路径正常第二条生成 1 个 CPU 工作进程跑 10 秒观察它能否正常启动和自动退出第三条配合查看 load average 是否升高。正常执行到这一步离线安装就算完成了。第一轮压测我建议用小参数目的不是压垮系统而是确认二进制能跑、不会一启动就段错误。等确认没问题再上大压力。5. 离线安装 stress 的常见坑与排查repomd.xml、Failed dependencies 和其它玄学离线安装 stress 本身不复杂但实际执行时总会在奇怪的环节卡住。这一章把我在不同内网环境里反复遇到的五类问题列出来每一条都按「现象、原因、解决」来写方便你出了问题直接照着查。5.1 离线机器上执行任何 yum 命令都报 repomd.xml [Errno -1]现象在离线机器上执行yum install stress或yum makecache命令卡住几十秒最后报错形如http://mirrors.aliyun.com/centos/7/os/x86_64/repodata/repomd.xml: [Errno -1] ...原因这台机器没有外网但 /etc/yum.repos.d/ 下的 repo 文件仍然指向公网镜像源。yum 拿到命令后第一件事就是去读取所有 enabled repo 的 repomd.xml 元数据连不上就超时。这个报错和 stress 本身无关是 yum 机制导致的必然结果。解决把公网源禁用掉。在 /etc/yum.repos.d/ 下建立一个 backup 目录把现有 .repo 全部移进去然后用yum --disablerepo*执行本地安装。如果确实需要保留一个指向内网私有源的 repo就把它的 baseurl 改成 file:// 本机路径并确保路径下有 repodata。离线环境下不要再去尝试 makecache因为没有任何外网源可供刷新。5.2 rpm 安装时报 Failed dependencies而且提示的依赖肉眼可见是存在的现象执行rpm -ivh stress-*.rpm报错error: Failed dependencies: libc.so.6()(64bit) is needed by stress-1.0.4-1.el7.x86_64原因报错内容让人格外困惑因为目标机明明有 /lib64/libc.so.6。这里的关键在于 rpm 检查的不是文件是否存在而是这个库文件能否提供对应的GLIBC_2.x符号。如果目标机 glibc 版本比生成 rpm 时的版本旧就会报这种「明明存在却说缺」的假错误。解决先确认目标机 glibc 版本ldd --version | head -1。如果版本明显低于 rpm 的要求不要尝试升级 glibcCentOS 7 上强行升级 glibc 会导致几乎全线工具崩掉。正确做法是回到有网机器从对应系统版本的 EPEL 源里重新下载旧版本 stress。如果版本一致仍然报错再用yum localinstall让 yum 预处理依赖往往能自动解决 rpm 手动安装时的小毛病。5.3 在 CentOS 7 上装了一个看起来正常的包运行报段错误现象stress 能装完但一运行就崩溃终端输出Segmentation fault或者stress: error while loading shared libraries: libc.so.6: cannot open shared object file原因最常见的是包版本对不上。比如在 CentOS 8 或者 CentOS 7.9 以外的系统上使用 EPEL 8 的 stress rpm 包或者下载时拿到了 aarch64 的包却在 x86_64 机器上安装。rpm 包名上的el7、el8和架构名就是这个问题的直接线索。解决在安装前跑一遍rpm -qpi stress-*.rpm查看包的 Architecture 和 Vendor 信息对照目标机uname -m。如果发现装错了先卸载再装正确版本rpm -e stress rpm -ivh stress-1.0.4-1.el7.x86_64.rpm这里哭声最大的场景是企业里有不同版本的 CentOS像 7.6、7.9、8.5 混着用拉包时拿错一台机器的版本传输完成后才发现。所以我现在的习惯是打包时就在目录名里标注系统版本和架构比如stress-rpm-centos7-x86_64从源头杜绝混乱。5.4 本地 yum 源配好了但 yum localinstall 仍然报 No package stress available现象把 rpm 都放在 /opt/localrepo 下也写了 /etc/yum.repos.d/local.repo但执行yum localinstall stress时提示找不到包。原因本地 yum 源目录下只有 rpm 文件没有 repodata 目录。yum 无法从纯 rpm 文件目录里解析元数据自然找不到包。很多人不知道 createrepo 这个工具是必须的。解决在放 rpm 的目录里生成索引yum install -y createrepo cd /opt/localrepo createrepo .然后执行yum clean all清掉旧的缓存索引。如果离线机器上没有 createrepo 且无法安装就在有网机器上生成好 repodata 目录连同 rpm 一起拷贝到内网。这个坑不限于 stress以后离线装任何工具都会遇到值得记住。5.5 同一个包出现多个版本通配符安装时版本冲突现象目录里有 stress-1.0.4 和 stress-1.0.5 两个 rpm执行rpm -ivh /opt/stress-rpm/*.rpm时报文件冲突或者版本冲突。原因通配符把所有 rpm 都传给 rpm 命令两个版本会争抢同一个安装路径。这类问题通常是因为在有网机器上下载目录复用了原目录里面残留了上一次拉包的旧文件。解决安装前先清理目录只保留需要的版本ls -l /opt/stress-rpm/ rm -f /opt/stress-rpm/stress-1.0.4*.rpm或者用一个干净的临时目录重新解压 tar 包。更保险的做法是下载时把输出目录设为专用路径比如带时间戳的 /opt/stress-rpm-20240315避免复用旧目录产生混乱。这也是打包规范里最容易被忽略的一条。6. 装完不急着收工先用 stress 压一轮 CPU再把监控命令一并练熟离线安装成功的标准不是 rpm 命令输出 success而是 stress 能压出真实负载、系统能扛住、你还能把进程安全回收。装完后的第一件事我建议做一次组合压测把 CPU、内存和磁盘 IO 一起拉起来看看stress -c 2 -m 1 --vm-bytes 256M -d 1 --hdd-bytes 512M -t 60-c 2生成两个 CPU 进程-m 1 --vm-bytes 256M让一个进程持续分配和释放 256M 内存-d 1 --hdd-bytes 512M让一个进程不断写磁盘-t 60限制整个压测只跑 60 秒。跑的时候打开另一个 SSH 窗口用mpstat -P ALL 1看每颗核的使用率用free -h看内存变化用iostat -x 1看磁盘队列。没有这些工具就用top按 1 展开所有核一样能看出负载分布。组合压测必须注意磁盘剩余空间。stress 的-d参数会创建文件并写入数据--hdd-bytes 512M只是它分配单次写入块的大小实际占用空间会显著超过这个值。我见过有人直接stress -d 1 -t 300跑五分钟把 /tmp 所在的根分区写满最后系统日志都打不出来。所以压测前先df -h并尽量给-d指定一个空间充足的目录。还有一个每个运维都应该养成的习惯给 stress 套上 timeout 和 nohup。压测经常是挂在后台跑的一旦 SSH 断开stress 会一直留在系统里继续吃资源。你也不知道它什么时候能回来只能靠超时机制兜底timeout 300 nohup stress -c 8 -t 60 /tmp/stress.log 21 这条命令把 stress 放到后台60 秒后自动结束即使 SSH 断掉也会在 300 秒的 timeout 硬边界内被强制终止。日志写到 /tmp/stress.log 方便回看进程列表则用pgrep -a stress随时检查。我早年因为少写 timeout在一台离线测试机上留下了 8 个占满 CPU 的 stress 进程最后靠pkill -9 stress才救回来。现在每次压测前都默认带 timeout这个习惯帮我在离线环境里省了不少清理时间。离线装好 stress 只是开始能安全地压、干净地收尾才算真正把工具用起来。希望帮到你。本文还有配套的精品资源点击获取