简介面向需要在无外网或内网CentOS环境中开展性能压测的运维、测试与Linux学习者这份资料围绕stress-1.0.4的离线部署整理重点解决压测工具及编译依赖难以在线获取的问题。压缩包共43个文件约46.66MB以11个rpm安装包和stress-1.0.4源码文件为主并包含configure、install-sh、depcomp等编译辅助脚本以及readme、info、html等说明文档便于按需安装依赖、完成源码编译和参数查阅。资料中涉及sar命令与Linux性能压测场景可用于CPU、内存、IO等负载测试时同步观察系统指标帮助读者在隔离网络下快速搭建可用的压力测试环境。已有2598人学习下载适合希望减少环境准备阻力、积累离线部署与性能观测经验的中级Linux使用者参考。1. CentOS 离线装 stress内网机器卡住的那一步内网那台 CentOS 7 上敲yum install -y stress回车之后滚出一行Cannot find a valid baseurl for repo: base/7/x86_64然后光标就停在那儿等三十秒再超时退出。第一次遇到会以为是源配错了翻半天/etc/yum.repos.d最后才反应过来这台机器压根没有外网而 stress 本身也不在发行版自带的 base 源里它在 EPEL。这种情况在机房、实验室、生产隔离区里太常见了。Linux 压力测试躲不开它可很多人图省事用dd if/dev/zero of/dev/null或者一个空转的 shell 循环顶一下结果要么压不满多核要么内存一路吃穿被 OOM 干掉跑出来的数据根本没法复盘。stress 这套东西包不大、依赖也浅麻烦全堆在取包和装进去这两步上。下面从选包一路写到验证照着走一遍一台没网的机器也能把压测环境立起来。2. 选包与摸依赖stress-1.0.4 和 stress-ng 的离线包清单怎么定离线安装翻车最多的一步不在装在取包取错了口径。CentOS 7 的包扔到 CentOS 8 上、x86_64 的包扔到 aarch64 上rpm -ivh当场就给你看红色错误。所以别急着找下载地址先把目标机的底量清楚再决定拿哪几个 rpm。2.1 先量目标机的底release、架构、glibc拿到一台陌生机器我一般先跑这四条三十秒的事能省掉后面半小时的试错。# 目标机执行把发行版、架构、glibc 口径一次问清 cat /etc/centos-release # 例CentOS Linux release 7.9.2009 (Core) uname -m # x86_64 / aarch64 getconf GNU_LIBC_VERSION # 例glibc 2.17 rpm -q glibc libgcc --qf %{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n逻辑说明/etc/centos-release决定你该拿.el7还是.el8后缀的包这是第一道分流uname -m决定架构aarch64 的机器装 x86_64 的包一定失败没有任何绕法getconf GNU_LIBC_VERSION是最硬的门槛二进制是在哪个 glibc 上编译的目标机就只能同版本或更高低了会在运行时报version GLIBC_2.14 not found这个错跟 rpm 安装阶段无关装的时候一切正常跑起来才炸最难查。最后那条rpm -q把 glibc 的完整 NEVRA 打出来后面挑包时用来对齐比rpm -qa | grep glibc干净得多。参数说明--qf里的%{NAME}、%{VERSION}、%{RELEASE}、%{ARCH}都是 rpm 的标签占位符\n是换行别漏。查多个包时把它们并列写在rpm -q后面即可。量完之后照着下面这张表对号入座基本不会拿错包目标机包后缀取包来源备注CentOS 7.x.el7.x86_64.rpmEPEL 7 base 7glibc 2.17老内核stress-ng 部分 stressor 不支持CentOS 8.x.el8.x86_64.rpmEPEL 8 base 8glibc 2.28yum与dnf命令可混用CentOS 7 aarch64.el7.aarch64.rpmEPEL 7 的 aarch64 分支别拿 x86_64 的包改名充数装了也跑不起来有一点要提前说清楚stress 本体在 EPEL不在安装 ISO 里。很多人抱着我有 DVD 镜像就万事大吉的想法mount 上去yum --repofrompath一查No package stress available白折腾。ISO 只能补 glibc、libgcc 这类底座依赖主包还是得从 EPEL 取。2.2 stress 与 stress-ng 的取舍这两个名字容易混离线场景下差别很大选错了取包清单直接翻倍。stress 是老牌工具一个二进制几百 KB依赖基本只有 glibc 和 libgccCentOS 7 上 EPEL 提供的是stress-1.0.4。它能干的活就四类--cpu压核、--vm压内存、--io压同步 IO、--hdd压磁盘写。参数简单--timeout到点自停适合做这台机器满载会不会抖这类粗粒度验证。缺点是它早就不更新了没有指标输出没有校验压完只知道跑完了压出多少量得自己从top里看。stress-ng 是后来者stressor 数量多一个量级CPU、内存、IO、网络、syscall、调度、缓存都能压还带--metrics-brief输出 bogo ops 数据带--verify做数据校验能做压完比对这种需要证据的测试。代价是包更大、依赖更多离线清单要长一截而且部分 stressor 依赖较新的内核特性CentOS 7 的 3.10 内核上会直接报不支持得一个个试。我的取舍标准很朴素只想验证 CPU 打得满不满、内存分配会不会出问题装 stress 就够了离线成本最低一个 rpm 加两三个底座包U 盘一拷就完事要做 IO 深度测试、要看量化指标、要跑带校验的数据通路那就上 stress-ng多带十几个包也认了。两个都装也不冲突命令名不一样各自独立。2.3 用 rpm -qpR 把依赖链摸干净包拿到手别急着往目标机扔。先在任意一台有 rpm 的机器上把包的依赖声明打出来看一遍这一步能把后面 80% 的报错提前掐掉。# 在取包机上执行看主包声明了哪些依赖 rpm -qpR stress-1.0.4-1.el7.x86_64.rpm # 批量扫一个目录下所有 rpm过滤掉 rpmlib 特性只留真正要找的 soname for p in /tmp/stress-pkg/*.rpm; do echo $p rpm -qpR $p | grep -v ^rpmlib | grep -v ^/bin/sh done逻辑说明rpm -qpR里的-p表示查询的是文件而不是已安装的包-R是 requires。输出里以rpmlib(...)开头的行是 rpm 自身的特性标记比如rpmlib(CompressedFileNames)它跟系统里装没装某个库无关是 rpm 版本的能力声明全部忽略。/bin/sh这种也别管最小化安装也一定有。剩下形如libc.so.6(GLIBC_2.14)(64bit)、libgcc_s.so.1(GCC_4.3.0)(64bit)的才是真正要找的 soname。再用下面这段把在当前机器上找不到提供者的依赖挑出来一目了然# 逐条依赖反查是哪个包提供的查不到就标记 MISSING rpm -qpR stress-1.0.4-1.el7.x86_64.rpm \ | grep -v ^rpmlib \ | while read -r cap; do rpm -q --whatprovides $cap /dev/null 21 || echo MISSING: $cap done参数说明rpm -q --whatprovides是反查能力提供者管道里read -r的-r防止反斜杠被吞。注意这段必须在与目标机同版本的机器上跑在 CentOS 8 上查 CentOS 7 的包结果没意义。查出来 MISSING 的条目就是你在取包机上必须补齐的东西。这里还有个血泪经验ldd看着更直观但别拿它当离线依赖的依据。ldd读的是某个具体二进制在当前机器上实际链接到的库换一台机器路径、版本都可能变rpm -qpR读的是包内的声明才是跨机器可用的口径。3. 取包在联网机上把 stress 的 rpm 连同依赖一次抓全依赖摸清了接下来找个同版本、能上外网的机器当取包机。这台机器不需要跟目标机硬件一样但 release 和架构必须一致否则下下来的包后缀对不上。取包有三条路按省事程度排yumdownloader→ 安装 ISO 补底座 → 源码编译。3.1 yumdownloader 的 --resolve 与 --alldeps这条是首选前提是取包机能连上 EPEL。# 取包机装工具、挂 EPEL、把 stress 和它的依赖一起下到指定目录 yum install -y yum-utils yum install -y epel-release # stress 在 EPELbase 源里没有 mkdir -p /tmp/stress-pkg yumdownloader --resolve --alldeps --destdir/tmp/stress-pkg stress ls -lh /tmp/stress-pkg逻辑说明--resolve让 yumdownloader 顺着依赖往下拉这是它能一次抓全的关键--alldeps是很多人漏掉的那个开关作用是把已经安装在取包机上的依赖也一起下载。不加它glibc、libgcc 这些因为取包机自己早就装了会被判定为已满足直接跳过结果拷到目标机一装就报Failed dependencies。这个坑我踩过不止一次抓下来的目录看着有包一数只有主包孤零零一个。参数说明--destdir指定落盘目录必须提前mkdiryumdownloader 不会自己建--archlistx86_64,noarch可以显式限定架构避免把 i686 的老包也拖下来在 64 位机器上默认不会但显式写一遍心里踏实。换成yum install --downloadonly也能达到类似效果# 另一种写法走完整事务解析只下载不安装 yum install --downloadonly --downloaddir/tmp/stress-pkg stress两者差别在于--downloadonly走的是完整的 yum 事务解析会告诉你将要安装哪些包输出更接近真实安装过程适合先看一眼清单再决定但它对已安装的包同样是跳过的补不齐底座依赖。所以我的习惯是先用--downloadonly看一眼事务确认要装哪些再用yumdownloader --resolve --alldeps把整包集合抓下来。装 stress-ng 同理把包名换掉就行。只是 stress-ng 的依赖会多出好几个抓完ls数一下一般十几个包是正常量级如果只有两三个八成又是--alldeps忘了加。3.2 只有安装 ISO 时怎么补底座依赖有些环境连 EPEL 都够不着手上只有一张 CentOS 的 DVD 镜像。这时候 ISO 能解决底座依赖但解决不了主包得分两步走。# 取包机挂载安装 ISO从本地镜像源补 glibc、libgcc 这类底座包 mkdir -p /mnt/iso mount -o loop,ro CentOS-7-x86_64-DVD-2009.iso /mnt/iso yum --disablerepo* \ --repofrompathiso,file:///mnt/iso \ --nogpgcheck \ install --downloadonly --downloaddir/tmp/base-pkg glibc libgcc逻辑说明--disablerepo*先把所有已配置的源关掉避免 yum 在连不通的外网源上干等超时--repofrompathiso,file:///mnt/iso临时挂一个源名字随便起file://后面跟挂载点注意是三个斜杠--nogpgcheck是因为本地 ISO 源没配 GPG key不加会卡在签名校验。参数说明mount -o loop,ro里的loop是把普通文件当块设备挂ro只读挂载防止误写镜像。ISO 里没有 stress 主包所以主包还是得从别处弄到——要么让另一台能上网的机器把 EPEL 的 rpm 下好拷过来要么直接下epel-release的 rpm 装到取包机上再走 3.1 的流程。顺带一句--repofrompath是临时源不落盘、不改/etc/yum.repos.d用完就没了比手写 repo 文件干净适合这种一次性操作。3.3 源码编译这条路什么时候值得走如果目标机上有完整的编译链gcc、make、glibc-devel 都在源码编译可以绕开 rpm 依赖体系把二进制直接编出来。# 取包机或目标机源码编译 stress装到 /usr/local/bin tar -xf stress-1.0.4.tar.gz cd stress-1.0.4 ./configure --prefix/usr/local make -j$(nproc) make install逻辑说明./configure会检查cc、头文件和stdint.h之类的基本前提缺了当场报错比装到一半失败好--prefix/usr/local把它放到独立目录跟包管理器装的/usr/bin/stress不打架也不污染系统路径make -j$(nproc)并行编译几十秒的事。但这条路我不太推荐原因很实在离线机器上往往没有glibc-devel和gcc为了装个压测工具去补一整条编译链成本比拷几个 rpm 高得多。而且make install出来的东西没有 uninstall删起来得手动对着install -t的路径一个个找。它真正值得用的场景只有一个——目标机的 glibc 太老连对应 el 版本的最低要求都够不上只能就地编。真到了这一步还要确认ldd --version的输出能在编译后保持一致否则编出来照样跑不起来。3.4 校验、打包与跨网传送包齐了别直接 scp 过去先打成一个包并留一份校验和。# 取包机打包 生成校验和 cd /tmp tar -czf stress-offline-$(date %Y%m%d).tar.gz -C /tmp stress-pkg sha256sum stress-offline-*.tar.gz | tee stress-offline.sha256 # 目标机解包后先校验再动 rpm tar -xzf stress-offline-20250101.tar.gz -C /tmp sha256sum -c /tmp/stress-offline.sha256逻辑说明-C /tmp让 tar 切到/tmp再打包这样归档里的路径是stress-pkg/...而不是一长串绝对路径解包时不至于覆盖别处文件。tee一边写文件一边打屏省得再cat一次sha256sum -c校验失败会直接报 FAILED比文件大小看着差不多可靠得多。参数说明传送方式看环境能 scp 就 scp隔离区一般走堡垒机文件通道或者一次性 U 盘。跨网传二进制文件最怕中途截断校验和就是这道闸。另外rpm 自身的签名也能校验前提是导入了 EPEL 的 GPG keyrpm --checksig /tmp/stress-pkg/stress-1.0.4-1.el7.x86_64.rpm离线机没导入 key 的话会显示digests SIGNATURES NOT OK这只是没有公钥可以验不代表包被改过别被吓到。真要严谨就把 EPEL 的 key 一并拷过去rpm --import一次导入长期有效。4. 目标机安装rpm 直装、yum localinstall 与临时本地源包到了目标机安装这一步反而不难难在选对方式。单包直装、批量装、搭本地源三种方式的适用场景不一样混用容易出依赖顺序的乱子。4.1 rpm -ivh 的正确用法和 --test 预演只有一个主包、依赖也都现成的时候直接rpm -ivh最快。但正式装之前先跑一遍--test。# 目标机只做依赖与冲突检查不落盘 rpm -ivh --test /tmp/stress-pkg/stress-1.0.4-1.el7.x86_64.rpm # 确认无误后正式安装 rpm -ivh /tmp/stress-pkg/stress-1.0.4-1.el7.x86_64.rpm逻辑说明--test会完整走一遍依赖解析和文件冲突检查但不写任何文件。返回空或者只有一句warning: ... already installed说明可以装报error: Failed dependencies:后面跟一串 soname就说明依赖还缺回去补包。这一步的价值在于正式安装中途失败会留下不完整状态虽然 rpm 有回滚但在生产机上多一次预演总归更放心。参数说明-i安装、-v显示过程、-h打进度条-h看着花哨但在装大包时能判断是不是卡住了。想升级已有包用-Uvh两者区别是-i遇到已安装包会跳过并提示-Uvh会真正替换。关于--nodeps我的态度很明确能不碰就不碰。它会把依赖检查整个关掉装是能装上但运行期一旦缺libgcc_s.so.1就是error while loading shared libraries这个错在压测跑到一半时才出现排查起来比装不上还费劲。真要用只在一种情况下确认缺的那个 soname 目标机上已经有等价实现只是 rpm 认不出来。用完之后立刻ldd $(which stress)逐个确认链接是否齐全把这一步当成必做的收尾动作。4.2 yum localinstall 解决依赖顺序依赖不止一两个的时候rpm -ivh *.rpm的毛病就出来了shell 通配符展开是按文件名字母序传参的依赖包排在后面rpm 装到前面那个就报缺失。哪怕全部包都在同一个目录顺序不对也白搭。# 目标机把所有 rpm 丢给 yum让它自己排依赖顺序 yum --disablerepo* --nogpgcheck localinstall -y /tmp/stress-pkg/*.rpm逻辑说明localinstall会把命令行上的本地 rpm 当成待装集合先做一次事务解析排出正确的安装顺序再逐个装。这样就绕开了手工排序的问题。--disablerepo*是关键一步目标机没网任何启用着的外网源都会让 yum 在解析阶段去连默认超时 30 秒乘以重试次数实际感受就是敲完命令卡了好几分钟才动加了这个开关立刻顺畅。参数说明--nogpgcheck在临时装内部包时用一下没关系但别写进长期的 repo 配置里。如果目标机的 yum 实在慢到离谱还有个更粗暴的做法把/etc/yum.repos.d整个改名备走装完再改回来效果一样。装完核对一下装了几个rpm -qa | grep -E ^stress # 看包是否登记 rpm -ql stress # 看文件清单rpm -ql输出很干净/usr/bin/stress加上一个 man 文档没有配置文件没有 systemd unit这是 stress 相比很多工具让人省心的地方——它不在系统里留任何常驻痕迹。4.3 createrepo 搭一个临时本地源如果同一个环境里要多台机器装或者后面还会反复装装删删那就别一台台拷 rpm 了搭个临时本地源更划算。# 目标机把包目录做成一个 yum 源 yum install -y createrepo # 离线机上没有就先从取包机带一个过来 createrepo /tmp/stress-pkg cat /etc/yum.repos.d/local-stress.repo EOF [local-stress] namelocal stress packages baseurlfile:///tmp/stress-pkg enabled0 gpgcheck0 EOF yum --enablerepolocal-stress install -y stress逻辑说明createrepo会在目录里生成repodata把一堆散装 rpm 变成一个 yum 能识别的源。repo 文件里enabled0是有意为之——平时不参与任何解析只有显式加--enablerepolocal-stress才启用避免哪天别人在这台机器上yum install别的东西时误从本地这个残缺源里取包。gpgcheck0只因为这是内部临时源用完即删。参数说明baseurlfile:///tmp/stress-pkg后面必须指向含repodata的那层目录指到上层会报Cannot retrieve repository metadata。createrepo这个包本身离线机大概率没有得从取包机一起带过来所以这条路的隐含成本比看起来高一点——如果只是为了装一个 stress直接走 4.2 更省事。用完清理rm -f /etc/yum.repos.d/local-stress.repo rm -rf /tmp/stress-pkg4.4 装到哪、怎么卸载干净装完心里要有个数文件落在哪、配置在哪、卸载会不会留尾巴。# 查文件清单、查是否有配置文件、卸载 rpm -ql stress rpm -qc stress # stress 没有配置文件这条会返回空 rpm -e stress # 卸载干净利落逻辑说明rpm -qc查的是 conffilesstress 返回空是正常的说明它不依赖任何/etc下的配置参数全靠命令行传。这意味着它不会跟系统里的其他东西产生配置层面的耦合也不存在卸载后配置文件残留的问题。rpm -e卸载只删这个包登记过的文件别的包的文件一个不碰。参数说明rpm -e后面跟包名不跟文件名写rpm -e stress-1.0.4-1.el7.x86_64也行写全路径不行。要连依赖一起清得手动一个个卸rpm 没有autoremove那是 yum 的事。跟源码编译装的方式对比这就是 rpm 的优势make install装进去的东西卸载时得自己回忆当时install到了哪些路径稍不留神就留一堆孤儿文件。所以只要能走 rpm我一般不选源码。5. 离线安装排查四个现场翻车的坑装工具这件事报错本身不可怕可怕的是报错信息指向的地方跟真实原因差着十万八千里。下面四个是这类环境里反复出现的记下来能省不少时间。5.1 依赖报错el7 的包扔到了 el6 上现象rpm -ivh直接报error: Failed dependencies: libc.so.6(GLIBC_2.14)(64bit) is needed by stress-1.0.4-1.el7.x86_64明明 glibc 就在系统里。原因包是按 el7 编的目标机是 CentOS 6glibc 只有 2.12提供不了 2.14 这个版本符号。rpm 的依赖匹配是精确到版本符号的libc.so.6存在不等于GLIBC_2.14存在。解决回到 2.1用cat /etc/centos-release确认目标机 release取对应后缀的包。CentOS 6 的 EPEL 里 stress 是老版本功能少一些但底子够用。真找不到对应包就走源码编译在目标机上就地编。5.2 包没装全yumdownloader 漏依赖现象取包机上跑完yumdownloader --resolve看着目录里有东西拷到目标机yum localinstall却报缺 glibc、libgcc。原因取包机上这些底座包本来就装着--resolve认为依赖已满足直接跳过不下载。解决加--alldeps。这是这个工具最容易忽略的参数加了之后它会把已安装的依赖也一并下载。抓完目录ls | wc -l数一下stress 一般三到五个包stress-ng 十几个数量对不上就是没抓全别急着拷。5.3 命令找不到PATH 与 hash 缓存现象rpm -q stress显示已安装rpm -ql也能看到/usr/bin/stress但敲stress --version就是command not found。原因多半是当前 shell 的 PATH 不含/usr/bin比如切换用户后环境变量被重置或者在某个受限的 shell 里操作。还有一种情况是之前敲过一次失败的命令shell 把找不到这个结果缓存进了 hash 表。解决先echo $PATH看一眼再hash -r清掉缓存重试。实在不行用绝对路径/usr/bin/stress --version验证二进制本身是好的。如果是 PATH 的问题export PATH/usr/bin:$PATH临时救急长期得改/etc/profile或者对应的用户级配置。5.4 压测把自己压断会话断开与资源限额现象stress --cpu 8 --timeout 600s跑着SSH 会话因为网络波动断了一下再连上去ps里什么都没有压测凭空消失或者命令在跑但top里 CPU 只上到 60% 就上不去了。原因前者是命令挂在当前会话的前台进程组里会话结束收到 SIGHUP 被一起带走。后者多半是 cgroup 限额容器的 CPU quota 卡在那里nproc看到的核数是宿主的实际可用没那么多。解决压测这种长任务别直接挂在前台用systemd-run起一个独立的 scope# 独立 scope 跑压测会话断了也不影响还能顺手限个额度 systemd-run --scope -p CPUQuota200% \ stress --cpu 4 --timeout 600s--scope让它脱离当前会话的进程组CPUQuota200%是给这台机器留余量防止压测把管理通道也拖死。至于核数对不上先cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us看一眼配额再决定传几个 worker。6. 验证跑通从 --version 到一轮能复现的压测装完不算完得能证明它真的把机器压起来了。我一般分三段验先确认装对了再确认参数认得最后跑一轮短压测看数据。# 第一段装对了没有 rpm -q stress rpm -ql stress | head /usr/bin/stress --version--version能打出stress ver 1.0.4就说明二进制可执行、动态链接没缺。如果这一步就报error while loading shared libraries回 4.1 查ldd $(which stress)别往下走了。第二段验参数# 第二段参数语法认不认注意 --timeout 支持 s/m/h/d 后缀不写默认秒 stress --cpu 1 --timeout 5s --verbose echo exit code: $?正常表现是输出一句stress: info: [pid] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd五秒后打successful run completed in 5s退出码 0。退出码这一步别省脚本化压测时全靠它判断成败。第三段跑一轮组合压测另开一个窗口看负载# 目标机窗口 ACPU 打满 内存分配60 秒后自停 stress --cpu $(nproc) --vm 2 --vm-bytes 512M --timeout 60s --verbose # 目标机窗口 B观察侧 top -b -n1 | head -15 uptime mpstat 1 5验证项命令正常表现包已登记rpm -q stress输出完整 NEVRA二进制可执行/usr/bin/stress --version打印版本号无 shared libraries 报错CPU 压得住stress --cpu $(nproc) --timeout 30s窗口 B 里%Cpu(s)的 us 接近 100内存压得住stress --vm 2 --vm-bytes 512M --timeout 30sfree -m的 used 上涨结束后回落磁盘压得住stress --hdd 2 --hdd-bytes 1G --timeout 30s当前目录出现大文件结束后自动删跑--hdd有个坑得提前看它会在当前工作目录写文件--hdd-bytes 1G乘上--hdd的 worker 数就是实际占用在根分区小的机器上容易把盘写满。我一般在/tmp或者单独的挂载点下跑跑完ls确认文件清掉了。另外--vm-bytes的总量要小于可用内存超了就是 OOM killer 上门压测变成事故。要指标的话用 stress-ng一条命令出汇总# stress-ng 的验证跑法metrics-brief 直接输出 bogo ops 数据 stress-ng --cpu 4 --vm 2 --vm-bytes 512M --timeout 60s --metrics-brief--metrics-brief会在结束时打出每个 stressor 的 bogo ops 和 real time这组数字是跨轮次对比的锚点——同一台机器同样的参数两轮 bogo ops 差太多说明机器本身状态不稳得先查硬件和后台进程别急着怀疑压测工具。从那以后我每次离线装完压测工具都强制走一遍这三段验证尤其是--version之后立刻ldd扫一眼链接绝不允许装上了但跑不起来的包留在机器上过夜。这套流程跑顺了一台隔离机器从拿到手到能压测前后不超过二十分钟。希望帮到你。本文还有配套的精品资源点击获取
简介面向需要在无外网或内网CentOS环境中开展性能压测的运维、测试与Linux学习者这份资料围绕stress-1.0.4的离线部署整理重点解决压测工具及编译依赖难以在线获取的问题。压缩包共43个文件约46.66MB以11个rpm安装包和stress-1.0.4源码文件为主并包含configure、install-sh、depcomp等编译辅助脚本以及readme、info、html等说明文档便于按需安装依赖、完成源码编译和参数查阅。资料中涉及sar命令与Linux性能压测场景可用于CPU、内存、IO等负载测试时同步观察系统指标帮助读者在隔离网络下快速搭建可用的压力测试环境。已有2598人学习下载适合希望减少环境准备阻力、积累离线部署与性能观测经验的中级Linux使用者参考。1. CentOS 离线装 stress内网机器卡住的那一步内网那台 CentOS 7 上敲yum install -y stress回车之后滚出一行Cannot find a valid baseurl for repo: base/7/x86_64然后光标就停在那儿等三十秒再超时退出。第一次遇到会以为是源配错了翻半天/etc/yum.repos.d最后才反应过来这台机器压根没有外网而 stress 本身也不在发行版自带的 base 源里它在 EPEL。这种情况在机房、实验室、生产隔离区里太常见了。Linux 压力测试躲不开它可很多人图省事用dd if/dev/zero of/dev/null或者一个空转的 shell 循环顶一下结果要么压不满多核要么内存一路吃穿被 OOM 干掉跑出来的数据根本没法复盘。stress 这套东西包不大、依赖也浅麻烦全堆在取包和装进去这两步上。下面从选包一路写到验证照着走一遍一台没网的机器也能把压测环境立起来。2. 选包与摸依赖stress-1.0.4 和 stress-ng 的离线包清单怎么定离线安装翻车最多的一步不在装在取包取错了口径。CentOS 7 的包扔到 CentOS 8 上、x86_64 的包扔到 aarch64 上rpm -ivh当场就给你看红色错误。所以别急着找下载地址先把目标机的底量清楚再决定拿哪几个 rpm。2.1 先量目标机的底release、架构、glibc拿到一台陌生机器我一般先跑这四条三十秒的事能省掉后面半小时的试错。# 目标机执行把发行版、架构、glibc 口径一次问清 cat /etc/centos-release # 例CentOS Linux release 7.9.2009 (Core) uname -m # x86_64 / aarch64 getconf GNU_LIBC_VERSION # 例glibc 2.17 rpm -q glibc libgcc --qf %{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n逻辑说明/etc/centos-release决定你该拿.el7还是.el8后缀的包这是第一道分流uname -m决定架构aarch64 的机器装 x86_64 的包一定失败没有任何绕法getconf GNU_LIBC_VERSION是最硬的门槛二进制是在哪个 glibc 上编译的目标机就只能同版本或更高低了会在运行时报version GLIBC_2.14 not found这个错跟 rpm 安装阶段无关装的时候一切正常跑起来才炸最难查。最后那条rpm -q把 glibc 的完整 NEVRA 打出来后面挑包时用来对齐比rpm -qa | grep glibc干净得多。参数说明--qf里的%{NAME}、%{VERSION}、%{RELEASE}、%{ARCH}都是 rpm 的标签占位符\n是换行别漏。查多个包时把它们并列写在rpm -q后面即可。量完之后照着下面这张表对号入座基本不会拿错包目标机包后缀取包来源备注CentOS 7.x.el7.x86_64.rpmEPEL 7 base 7glibc 2.17老内核stress-ng 部分 stressor 不支持CentOS 8.x.el8.x86_64.rpmEPEL 8 base 8glibc 2.28yum与dnf命令可混用CentOS 7 aarch64.el7.aarch64.rpmEPEL 7 的 aarch64 分支别拿 x86_64 的包改名充数装了也跑不起来有一点要提前说清楚stress 本体在 EPEL不在安装 ISO 里。很多人抱着我有 DVD 镜像就万事大吉的想法mount 上去yum --repofrompath一查No package stress available白折腾。ISO 只能补 glibc、libgcc 这类底座依赖主包还是得从 EPEL 取。2.2 stress 与 stress-ng 的取舍这两个名字容易混离线场景下差别很大选错了取包清单直接翻倍。stress 是老牌工具一个二进制几百 KB依赖基本只有 glibc 和 libgccCentOS 7 上 EPEL 提供的是stress-1.0.4。它能干的活就四类--cpu压核、--vm压内存、--io压同步 IO、--hdd压磁盘写。参数简单--timeout到点自停适合做这台机器满载会不会抖这类粗粒度验证。缺点是它早就不更新了没有指标输出没有校验压完只知道跑完了压出多少量得自己从top里看。stress-ng 是后来者stressor 数量多一个量级CPU、内存、IO、网络、syscall、调度、缓存都能压还带--metrics-brief输出 bogo ops 数据带--verify做数据校验能做压完比对这种需要证据的测试。代价是包更大、依赖更多离线清单要长一截而且部分 stressor 依赖较新的内核特性CentOS 7 的 3.10 内核上会直接报不支持得一个个试。我的取舍标准很朴素只想验证 CPU 打得满不满、内存分配会不会出问题装 stress 就够了离线成本最低一个 rpm 加两三个底座包U 盘一拷就完事要做 IO 深度测试、要看量化指标、要跑带校验的数据通路那就上 stress-ng多带十几个包也认了。两个都装也不冲突命令名不一样各自独立。2.3 用 rpm -qpR 把依赖链摸干净包拿到手别急着往目标机扔。先在任意一台有 rpm 的机器上把包的依赖声明打出来看一遍这一步能把后面 80% 的报错提前掐掉。# 在取包机上执行看主包声明了哪些依赖 rpm -qpR stress-1.0.4-1.el7.x86_64.rpm # 批量扫一个目录下所有 rpm过滤掉 rpmlib 特性只留真正要找的 soname for p in /tmp/stress-pkg/*.rpm; do echo $p rpm -qpR $p | grep -v ^rpmlib | grep -v ^/bin/sh done逻辑说明rpm -qpR里的-p表示查询的是文件而不是已安装的包-R是 requires。输出里以rpmlib(...)开头的行是 rpm 自身的特性标记比如rpmlib(CompressedFileNames)它跟系统里装没装某个库无关是 rpm 版本的能力声明全部忽略。/bin/sh这种也别管最小化安装也一定有。剩下形如libc.so.6(GLIBC_2.14)(64bit)、libgcc_s.so.1(GCC_4.3.0)(64bit)的才是真正要找的 soname。再用下面这段把在当前机器上找不到提供者的依赖挑出来一目了然# 逐条依赖反查是哪个包提供的查不到就标记 MISSING rpm -qpR stress-1.0.4-1.el7.x86_64.rpm \ | grep -v ^rpmlib \ | while read -r cap; do rpm -q --whatprovides $cap /dev/null 21 || echo MISSING: $cap done参数说明rpm -q --whatprovides是反查能力提供者管道里read -r的-r防止反斜杠被吞。注意这段必须在与目标机同版本的机器上跑在 CentOS 8 上查 CentOS 7 的包结果没意义。查出来 MISSING 的条目就是你在取包机上必须补齐的东西。这里还有个血泪经验ldd看着更直观但别拿它当离线依赖的依据。ldd读的是某个具体二进制在当前机器上实际链接到的库换一台机器路径、版本都可能变rpm -qpR读的是包内的声明才是跨机器可用的口径。3. 取包在联网机上把 stress 的 rpm 连同依赖一次抓全依赖摸清了接下来找个同版本、能上外网的机器当取包机。这台机器不需要跟目标机硬件一样但 release 和架构必须一致否则下下来的包后缀对不上。取包有三条路按省事程度排yumdownloader→ 安装 ISO 补底座 → 源码编译。3.1 yumdownloader 的 --resolve 与 --alldeps这条是首选前提是取包机能连上 EPEL。# 取包机装工具、挂 EPEL、把 stress 和它的依赖一起下到指定目录 yum install -y yum-utils yum install -y epel-release # stress 在 EPELbase 源里没有 mkdir -p /tmp/stress-pkg yumdownloader --resolve --alldeps --destdir/tmp/stress-pkg stress ls -lh /tmp/stress-pkg逻辑说明--resolve让 yumdownloader 顺着依赖往下拉这是它能一次抓全的关键--alldeps是很多人漏掉的那个开关作用是把已经安装在取包机上的依赖也一起下载。不加它glibc、libgcc 这些因为取包机自己早就装了会被判定为已满足直接跳过结果拷到目标机一装就报Failed dependencies。这个坑我踩过不止一次抓下来的目录看着有包一数只有主包孤零零一个。参数说明--destdir指定落盘目录必须提前mkdiryumdownloader 不会自己建--archlistx86_64,noarch可以显式限定架构避免把 i686 的老包也拖下来在 64 位机器上默认不会但显式写一遍心里踏实。换成yum install --downloadonly也能达到类似效果# 另一种写法走完整事务解析只下载不安装 yum install --downloadonly --downloaddir/tmp/stress-pkg stress两者差别在于--downloadonly走的是完整的 yum 事务解析会告诉你将要安装哪些包输出更接近真实安装过程适合先看一眼清单再决定但它对已安装的包同样是跳过的补不齐底座依赖。所以我的习惯是先用--downloadonly看一眼事务确认要装哪些再用yumdownloader --resolve --alldeps把整包集合抓下来。装 stress-ng 同理把包名换掉就行。只是 stress-ng 的依赖会多出好几个抓完ls数一下一般十几个包是正常量级如果只有两三个八成又是--alldeps忘了加。3.2 只有安装 ISO 时怎么补底座依赖有些环境连 EPEL 都够不着手上只有一张 CentOS 的 DVD 镜像。这时候 ISO 能解决底座依赖但解决不了主包得分两步走。# 取包机挂载安装 ISO从本地镜像源补 glibc、libgcc 这类底座包 mkdir -p /mnt/iso mount -o loop,ro CentOS-7-x86_64-DVD-2009.iso /mnt/iso yum --disablerepo* \ --repofrompathiso,file:///mnt/iso \ --nogpgcheck \ install --downloadonly --downloaddir/tmp/base-pkg glibc libgcc逻辑说明--disablerepo*先把所有已配置的源关掉避免 yum 在连不通的外网源上干等超时--repofrompathiso,file:///mnt/iso临时挂一个源名字随便起file://后面跟挂载点注意是三个斜杠--nogpgcheck是因为本地 ISO 源没配 GPG key不加会卡在签名校验。参数说明mount -o loop,ro里的loop是把普通文件当块设备挂ro只读挂载防止误写镜像。ISO 里没有 stress 主包所以主包还是得从别处弄到——要么让另一台能上网的机器把 EPEL 的 rpm 下好拷过来要么直接下epel-release的 rpm 装到取包机上再走 3.1 的流程。顺带一句--repofrompath是临时源不落盘、不改/etc/yum.repos.d用完就没了比手写 repo 文件干净适合这种一次性操作。3.3 源码编译这条路什么时候值得走如果目标机上有完整的编译链gcc、make、glibc-devel 都在源码编译可以绕开 rpm 依赖体系把二进制直接编出来。# 取包机或目标机源码编译 stress装到 /usr/local/bin tar -xf stress-1.0.4.tar.gz cd stress-1.0.4 ./configure --prefix/usr/local make -j$(nproc) make install逻辑说明./configure会检查cc、头文件和stdint.h之类的基本前提缺了当场报错比装到一半失败好--prefix/usr/local把它放到独立目录跟包管理器装的/usr/bin/stress不打架也不污染系统路径make -j$(nproc)并行编译几十秒的事。但这条路我不太推荐原因很实在离线机器上往往没有glibc-devel和gcc为了装个压测工具去补一整条编译链成本比拷几个 rpm 高得多。而且make install出来的东西没有 uninstall删起来得手动对着install -t的路径一个个找。它真正值得用的场景只有一个——目标机的 glibc 太老连对应 el 版本的最低要求都够不上只能就地编。真到了这一步还要确认ldd --version的输出能在编译后保持一致否则编出来照样跑不起来。3.4 校验、打包与跨网传送包齐了别直接 scp 过去先打成一个包并留一份校验和。# 取包机打包 生成校验和 cd /tmp tar -czf stress-offline-$(date %Y%m%d).tar.gz -C /tmp stress-pkg sha256sum stress-offline-*.tar.gz | tee stress-offline.sha256 # 目标机解包后先校验再动 rpm tar -xzf stress-offline-20250101.tar.gz -C /tmp sha256sum -c /tmp/stress-offline.sha256逻辑说明-C /tmp让 tar 切到/tmp再打包这样归档里的路径是stress-pkg/...而不是一长串绝对路径解包时不至于覆盖别处文件。tee一边写文件一边打屏省得再cat一次sha256sum -c校验失败会直接报 FAILED比文件大小看着差不多可靠得多。参数说明传送方式看环境能 scp 就 scp隔离区一般走堡垒机文件通道或者一次性 U 盘。跨网传二进制文件最怕中途截断校验和就是这道闸。另外rpm 自身的签名也能校验前提是导入了 EPEL 的 GPG keyrpm --checksig /tmp/stress-pkg/stress-1.0.4-1.el7.x86_64.rpm离线机没导入 key 的话会显示digests SIGNATURES NOT OK这只是没有公钥可以验不代表包被改过别被吓到。真要严谨就把 EPEL 的 key 一并拷过去rpm --import一次导入长期有效。4. 目标机安装rpm 直装、yum localinstall 与临时本地源包到了目标机安装这一步反而不难难在选对方式。单包直装、批量装、搭本地源三种方式的适用场景不一样混用容易出依赖顺序的乱子。4.1 rpm -ivh 的正确用法和 --test 预演只有一个主包、依赖也都现成的时候直接rpm -ivh最快。但正式装之前先跑一遍--test。# 目标机只做依赖与冲突检查不落盘 rpm -ivh --test /tmp/stress-pkg/stress-1.0.4-1.el7.x86_64.rpm # 确认无误后正式安装 rpm -ivh /tmp/stress-pkg/stress-1.0.4-1.el7.x86_64.rpm逻辑说明--test会完整走一遍依赖解析和文件冲突检查但不写任何文件。返回空或者只有一句warning: ... already installed说明可以装报error: Failed dependencies:后面跟一串 soname就说明依赖还缺回去补包。这一步的价值在于正式安装中途失败会留下不完整状态虽然 rpm 有回滚但在生产机上多一次预演总归更放心。参数说明-i安装、-v显示过程、-h打进度条-h看着花哨但在装大包时能判断是不是卡住了。想升级已有包用-Uvh两者区别是-i遇到已安装包会跳过并提示-Uvh会真正替换。关于--nodeps我的态度很明确能不碰就不碰。它会把依赖检查整个关掉装是能装上但运行期一旦缺libgcc_s.so.1就是error while loading shared libraries这个错在压测跑到一半时才出现排查起来比装不上还费劲。真要用只在一种情况下确认缺的那个 soname 目标机上已经有等价实现只是 rpm 认不出来。用完之后立刻ldd $(which stress)逐个确认链接是否齐全把这一步当成必做的收尾动作。4.2 yum localinstall 解决依赖顺序依赖不止一两个的时候rpm -ivh *.rpm的毛病就出来了shell 通配符展开是按文件名字母序传参的依赖包排在后面rpm 装到前面那个就报缺失。哪怕全部包都在同一个目录顺序不对也白搭。# 目标机把所有 rpm 丢给 yum让它自己排依赖顺序 yum --disablerepo* --nogpgcheck localinstall -y /tmp/stress-pkg/*.rpm逻辑说明localinstall会把命令行上的本地 rpm 当成待装集合先做一次事务解析排出正确的安装顺序再逐个装。这样就绕开了手工排序的问题。--disablerepo*是关键一步目标机没网任何启用着的外网源都会让 yum 在解析阶段去连默认超时 30 秒乘以重试次数实际感受就是敲完命令卡了好几分钟才动加了这个开关立刻顺畅。参数说明--nogpgcheck在临时装内部包时用一下没关系但别写进长期的 repo 配置里。如果目标机的 yum 实在慢到离谱还有个更粗暴的做法把/etc/yum.repos.d整个改名备走装完再改回来效果一样。装完核对一下装了几个rpm -qa | grep -E ^stress # 看包是否登记 rpm -ql stress # 看文件清单rpm -ql输出很干净/usr/bin/stress加上一个 man 文档没有配置文件没有 systemd unit这是 stress 相比很多工具让人省心的地方——它不在系统里留任何常驻痕迹。4.3 createrepo 搭一个临时本地源如果同一个环境里要多台机器装或者后面还会反复装装删删那就别一台台拷 rpm 了搭个临时本地源更划算。# 目标机把包目录做成一个 yum 源 yum install -y createrepo # 离线机上没有就先从取包机带一个过来 createrepo /tmp/stress-pkg cat /etc/yum.repos.d/local-stress.repo EOF [local-stress] namelocal stress packages baseurlfile:///tmp/stress-pkg enabled0 gpgcheck0 EOF yum --enablerepolocal-stress install -y stress逻辑说明createrepo会在目录里生成repodata把一堆散装 rpm 变成一个 yum 能识别的源。repo 文件里enabled0是有意为之——平时不参与任何解析只有显式加--enablerepolocal-stress才启用避免哪天别人在这台机器上yum install别的东西时误从本地这个残缺源里取包。gpgcheck0只因为这是内部临时源用完即删。参数说明baseurlfile:///tmp/stress-pkg后面必须指向含repodata的那层目录指到上层会报Cannot retrieve repository metadata。createrepo这个包本身离线机大概率没有得从取包机一起带过来所以这条路的隐含成本比看起来高一点——如果只是为了装一个 stress直接走 4.2 更省事。用完清理rm -f /etc/yum.repos.d/local-stress.repo rm -rf /tmp/stress-pkg4.4 装到哪、怎么卸载干净装完心里要有个数文件落在哪、配置在哪、卸载会不会留尾巴。# 查文件清单、查是否有配置文件、卸载 rpm -ql stress rpm -qc stress # stress 没有配置文件这条会返回空 rpm -e stress # 卸载干净利落逻辑说明rpm -qc查的是 conffilesstress 返回空是正常的说明它不依赖任何/etc下的配置参数全靠命令行传。这意味着它不会跟系统里的其他东西产生配置层面的耦合也不存在卸载后配置文件残留的问题。rpm -e卸载只删这个包登记过的文件别的包的文件一个不碰。参数说明rpm -e后面跟包名不跟文件名写rpm -e stress-1.0.4-1.el7.x86_64也行写全路径不行。要连依赖一起清得手动一个个卸rpm 没有autoremove那是 yum 的事。跟源码编译装的方式对比这就是 rpm 的优势make install装进去的东西卸载时得自己回忆当时install到了哪些路径稍不留神就留一堆孤儿文件。所以只要能走 rpm我一般不选源码。5. 离线安装排查四个现场翻车的坑装工具这件事报错本身不可怕可怕的是报错信息指向的地方跟真实原因差着十万八千里。下面四个是这类环境里反复出现的记下来能省不少时间。5.1 依赖报错el7 的包扔到了 el6 上现象rpm -ivh直接报error: Failed dependencies: libc.so.6(GLIBC_2.14)(64bit) is needed by stress-1.0.4-1.el7.x86_64明明 glibc 就在系统里。原因包是按 el7 编的目标机是 CentOS 6glibc 只有 2.12提供不了 2.14 这个版本符号。rpm 的依赖匹配是精确到版本符号的libc.so.6存在不等于GLIBC_2.14存在。解决回到 2.1用cat /etc/centos-release确认目标机 release取对应后缀的包。CentOS 6 的 EPEL 里 stress 是老版本功能少一些但底子够用。真找不到对应包就走源码编译在目标机上就地编。5.2 包没装全yumdownloader 漏依赖现象取包机上跑完yumdownloader --resolve看着目录里有东西拷到目标机yum localinstall却报缺 glibc、libgcc。原因取包机上这些底座包本来就装着--resolve认为依赖已满足直接跳过不下载。解决加--alldeps。这是这个工具最容易忽略的参数加了之后它会把已安装的依赖也一并下载。抓完目录ls | wc -l数一下stress 一般三到五个包stress-ng 十几个数量对不上就是没抓全别急着拷。5.3 命令找不到PATH 与 hash 缓存现象rpm -q stress显示已安装rpm -ql也能看到/usr/bin/stress但敲stress --version就是command not found。原因多半是当前 shell 的 PATH 不含/usr/bin比如切换用户后环境变量被重置或者在某个受限的 shell 里操作。还有一种情况是之前敲过一次失败的命令shell 把找不到这个结果缓存进了 hash 表。解决先echo $PATH看一眼再hash -r清掉缓存重试。实在不行用绝对路径/usr/bin/stress --version验证二进制本身是好的。如果是 PATH 的问题export PATH/usr/bin:$PATH临时救急长期得改/etc/profile或者对应的用户级配置。5.4 压测把自己压断会话断开与资源限额现象stress --cpu 8 --timeout 600s跑着SSH 会话因为网络波动断了一下再连上去ps里什么都没有压测凭空消失或者命令在跑但top里 CPU 只上到 60% 就上不去了。原因前者是命令挂在当前会话的前台进程组里会话结束收到 SIGHUP 被一起带走。后者多半是 cgroup 限额容器的 CPU quota 卡在那里nproc看到的核数是宿主的实际可用没那么多。解决压测这种长任务别直接挂在前台用systemd-run起一个独立的 scope# 独立 scope 跑压测会话断了也不影响还能顺手限个额度 systemd-run --scope -p CPUQuota200% \ stress --cpu 4 --timeout 600s--scope让它脱离当前会话的进程组CPUQuota200%是给这台机器留余量防止压测把管理通道也拖死。至于核数对不上先cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us看一眼配额再决定传几个 worker。6. 验证跑通从 --version 到一轮能复现的压测装完不算完得能证明它真的把机器压起来了。我一般分三段验先确认装对了再确认参数认得最后跑一轮短压测看数据。# 第一段装对了没有 rpm -q stress rpm -ql stress | head /usr/bin/stress --version--version能打出stress ver 1.0.4就说明二进制可执行、动态链接没缺。如果这一步就报error while loading shared libraries回 4.1 查ldd $(which stress)别往下走了。第二段验参数# 第二段参数语法认不认注意 --timeout 支持 s/m/h/d 后缀不写默认秒 stress --cpu 1 --timeout 5s --verbose echo exit code: $?正常表现是输出一句stress: info: [pid] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd五秒后打successful run completed in 5s退出码 0。退出码这一步别省脚本化压测时全靠它判断成败。第三段跑一轮组合压测另开一个窗口看负载# 目标机窗口 ACPU 打满 内存分配60 秒后自停 stress --cpu $(nproc) --vm 2 --vm-bytes 512M --timeout 60s --verbose # 目标机窗口 B观察侧 top -b -n1 | head -15 uptime mpstat 1 5验证项命令正常表现包已登记rpm -q stress输出完整 NEVRA二进制可执行/usr/bin/stress --version打印版本号无 shared libraries 报错CPU 压得住stress --cpu $(nproc) --timeout 30s窗口 B 里%Cpu(s)的 us 接近 100内存压得住stress --vm 2 --vm-bytes 512M --timeout 30sfree -m的 used 上涨结束后回落磁盘压得住stress --hdd 2 --hdd-bytes 1G --timeout 30s当前目录出现大文件结束后自动删跑--hdd有个坑得提前看它会在当前工作目录写文件--hdd-bytes 1G乘上--hdd的 worker 数就是实际占用在根分区小的机器上容易把盘写满。我一般在/tmp或者单独的挂载点下跑跑完ls确认文件清掉了。另外--vm-bytes的总量要小于可用内存超了就是 OOM killer 上门压测变成事故。要指标的话用 stress-ng一条命令出汇总# stress-ng 的验证跑法metrics-brief 直接输出 bogo ops 数据 stress-ng --cpu 4 --vm 2 --vm-bytes 512M --timeout 60s --metrics-brief--metrics-brief会在结束时打出每个 stressor 的 bogo ops 和 real time这组数字是跨轮次对比的锚点——同一台机器同样的参数两轮 bogo ops 差太多说明机器本身状态不稳得先查硬件和后台进程别急着怀疑压测工具。从那以后我每次离线装完压测工具都强制走一遍这三段验证尤其是--version之后立刻ldd扫一眼链接绝不允许装上了但跑不起来的包留在机器上过夜。这套流程跑顺了一台隔离机器从拿到手到能压测前后不超过二十分钟。希望帮到你。本文还有配套的精品资源点击获取
