CentOS 7离线安装stress：rpm依赖解析与压测验证

简介：面向需要在无外网或内网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后面即可。

量完之后照着下面这张表对号入座，基本不会拿错包：

有一点要提前说清楚：stress 本体在 EPEL，不在安装 ISO 里。很多人抱着"我有 DVD 镜像就万事大吉"的想法，mount 上去yum --repofrompath一查，No package stress available，白折腾。ISO 只能补 glibc、libgcc 这类底座依赖，主包还是得从 EPEL 取。

2.2 stress 与 stress-ng 的取舍

这两个名字容易混，离线场景下差别很大，选错了取包清单直接翻倍。

stress 是老牌工具，一个二进制，几百 KB，依赖基本只有 glibc 和 libgcc，CentOS 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 2>&1 || 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 在 EPEL，base 源里没有 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指定落盘目录，必须提前mkdir，yumdownloader 不会自己建；--archlist=x86_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='*' \ --repofrompath=iso,file:///mnt/iso \ --nogpgcheck \ install --downloadonly --downloaddir=/tmp/base-pkg glibc libgcc

逻辑说明：--disablerepo='*'先把所有已配置的源关掉，避免 yum 在连不通的外网源上干等超时；--repofrompath=iso,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 key：

rpm --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] name=local stress packages baseurl=file:///tmp/stress-pkg enabled=0 gpgcheck=0 EOF yum --enablerepo=local-stress install -y stress

逻辑说明：createrepo会在目录里生成repodata，把一堆散装 rpm 变成一个 yum 能识别的源。repo 文件里enabled=0是有意为之——平时不参与任何解析，只有显式加--enablerepo=local-stress才启用，避免哪天别人在这台机器上yum install别的东西时，误从本地这个残缺源里取包。gpgcheck=0只因为这是内部临时源，用完即删。

参数说明：baseurl=file:///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-pkg

4.4 装到哪、怎么卸载干净

装完心里要有个数：文件落在哪、配置在哪、卸载会不会留尾巴。

# 查文件清单、查是否有配置文件、卸载 rpm -ql stress rpm -qc stress # stress 没有配置文件，这条会返回空 rpm -e stress # 卸载，干净利落

逻辑说明：rpm -qc查的是 conffiles，stress 返回空是正常的，说明它不依赖任何/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 6，glibc 只有 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 CPUQuota=200% \ stress --cpu 4 --timeout 600s

--scope让它脱离当前会话的进程组，CPUQuota=200%是给这台机器留余量，防止压测把管理通道也拖死。至于核数对不上，先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。退出码这一步别省，脚本化压测时全靠它判断成败。

第三段跑一轮组合压测，另开一个窗口看负载：

# 目标机窗口 A：CPU 打满 + 内存分配，60 秒后自停 stress --cpu "$(nproc)" --vm 2 --vm-bytes 512M --timeout 60s --verbose # 目标机窗口 B：观察侧 top -b -n1 | head -15 uptime mpstat 1 5

跑--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扫一眼链接，绝不允许"装上了但跑不起来"的包留在机器上过夜。这套流程跑顺了，一台隔离机器从拿到手到能压测，前后不超过二十分钟。希望帮到你。

本文还有配套的精品资源，点击获取