简介面向CentOS Linux服务器的离线安装场景这份资料提供stress-1.0.4压力测试工具及其编译安装所需的rpm依赖如gcc-g可帮助运维与开发人员在无外网或内网环境中快速完成Linux CPU/内存/IO性能压测并支持sar命令的配套使用。资源共43个文件压缩包约46.66MB主要包含rpm安装包、configure配置脚本、Makefile构建文件、C源码、texi/tex文档以及readme/install说明等整体属于“源码依赖构建说明”的离线部署组合。目前已有2582人学习/下载此资源。通过它可直接获得stress源码、预编译依赖包和清晰的安装引导免去手工寻找rpm与解决gcc缺失的麻烦尤其适合生产环境受限、仅能离线操作的CentOS主机安装后可快速用stress模拟高负载同时结合sar命令观察系统资源表现为容量评估与稳定性测试提供依据。1. 为什么要在 CentOS 上离线装 stress一次压测事故引出的问题去年给一台内网 CentOS 7.9 服务器做上线前压力测试机器在隔离区完全不能访问外网yum install stress 直接报 Could not resolve host被迫走 centos 离线安装 stress 的路线。当时整个人愣住了。后来才知道离线环境下装 linux 压测工具根本不是下载一个 rpm 那么简单依赖判断、包来源、装完验证每个环节都有坑。这篇文章就是我拆完这个场景后的完整落地记录覆盖 centos 离线安装 stress 的依赖分析、RPM 与源码两条安装路线、四类压测参数以及最容易翻车的几个细节。适合给内网服务器、云上隔离环境做压力测试的运维和开发参考新手能跟着步骤走熟手可以直接看避坑和参数边界。2. 离线安装前的准备依赖分析、ISO 挂载与离线包获取2.1 先确认依赖rpm -qpR 看 stress 到底要什么离线安装最忌讳直接双击 rpm 盲装。我拿到一份 stress 的 rpm 后习惯先做一次依赖体检确认它要哪些动态库和基础工具。在任意有 rpm 命令的机器上都可以执行rpm -qpR stress-1.0.4-16.el7.x86_64.rpm输出通常包含这样几行/bin/sh libc.so.6()(64bit) libgcc_s.so.1()(64bit) rpmlib(CompressedFileNames) 3.0.4-1这里的含义是 stress 运行时需要 64 位的 libc 和 libgcc。libc.so.6 由 glibc 提供libgcc_s.so.1 由 libgcc 提供这两项在正常 CentOS 7/8 系统上默认都是存在的可以用 rpm -q glibc libgcc 快速确认正常会输出软件包名和版本号。真正要小心的是 rpm 包名字里的 el7 和 el8 标识它表示这个包是针对哪个大版本编译的把 el7 的包装到 CentOS 8 上轻则版本依赖出错重则直接破坏系统里已有的库文件。这里还有一个容易被忽略的点stress 的 rpm 依赖里会出现 /bin/sh这意味着如果你用容器镜像或者精简系统来做压测shell 缺失同样会导致安装失败。所以拿到包的第一件事是核对系统版本和架构cat /etc/redhat-release uname -mcat 查看的是系统大版本uname -m 是架构x86_64 和 aarch64 的 stress 包完全不通用。这一步花不了三十秒但能避免后面一整轮的返工。我见过有人把 x86_64 的包拷到 arm 版 centos 上安装时直接报 Exec format error那才是真的无语。2.2 三种离线安装方案的选型对比离线安装 stress 不是只有一种正经办法。根据目标机器的环境和手头资源我一般从三条路线里选先用一张表把边界摆出来方案前置条件安装耗时适合场景rpm -ivh 直接安装拿到与系统版本匹配的 stress rpm依赖完整1 分钟内目标机器基础库完整追求快速yum localinstallrpm 包及其全部依赖都在本地目录1 分钟内依赖较多希望 yum 自动处理顺序源码编译安装目标机器存在 gcc、make、autoconf5 到 10 分钟找不到现成 rpm或系统比较新如 CentOS Stream大多数人第一反应是 rpm 直接装确实最快。但前提是你能拿到对应版本。CentOS 7.9 的官方 DVD 镜像里自带 stress-1.0.4-16.el7.x86_64.rpm直接挂载 ISO 就能找到CentOS 8 的 stress 放在 powertools 源里base 源没有。如果目标机器是 CentOS 8 Streamrpm 包依赖处理会复杂一些这时候源码编译反而是更可控的路线。源码编译的前提是目标机器有 gcc 和 make如果连 gcc 都没有你就要把 gcc、make 以及它们的一大堆依赖也一起离线打包工作量会明显变大。这也解释了我为什么一般优先尝试 rpm 路线它的依赖数量是确定且可穷举的而编译工具链的依赖数量翻几倍不止。选择方案时还有一个原则优先考虑与目标机器同版本同架构的 rpm其次才考虑源码编译因为编译虽然灵活但失去了 rpm 数据库的统一管理后续卸载和升级都要手动处理。2.3 从有网机器拉取离线包yumdownloader、repotrack 与 ISO 挂载确定走 rpm 路线后需要在一台能联网的同版本 CentOS 上离线拉包。最稳的方式是用 repotrack它可以连同运行时依赖一起拉下来不会漏包。先安装 yum-utilsyum install -y yum-utils repotrack stress -p /opt/stress_offline命令会以 /opt/stress_offline 为目标目录把 stress 以及它依赖的所有 rpm 全部落盘随后把这个目录整体拷到离线机器上即可。repotrack 的好处是依赖树完整省得装到一半发现缺个库又折返坏处是拉下来的包数量可能比你预期多传输时间稍长。如果你只需要单个包和它的直接依赖可以用 yumdownloaderyumdownloader --resolve --destdir/opt/stress_offline stress--resolve 表示同时下载依赖--destdir 指定输出目录。这里有个细节yumdownloader 的 --resolve 有时不会把当前系统已经存在的依赖重新拉一遍比如 glibc 已经在有网机器上它默认不用再下但离线机器如果刚好缺这个库装的时候就会报错。遇到这类情况回到有网机器上单独 yumdownloader glibc 再拷贝过去即可。第三个来源是 CentOS 官方 ISO 镜像。在 CentOS 7.9 下载页面拿到 DVD ISO 后挂载到任意目录mkdir -p /mnt/iso mount -o loop CentOS-7-x86_64-DVD-2009.iso /mnt/iso find /mnt/iso/Packages -name stress*挂载成功后Packages 目录里能看到 stress-1.0.4-16.el7.x86_64.rpm。ISO 里的包都经过官方签名版本和系统严格对应是离线机器上最可靠的包来源。挂载用完记得 umount /mnt/iso 释放资源。要注意 DVD ISO 体积通常在 4G 左右如果只是为了拿一个 stress 包挂载后找到 rpm 复制出来就行不需要把整个 ISO 传到目标机器。离线包准备好之后传输也有讲究。我一般用 scp 或者 U 盘拷贝scp 命令如下scp -r /opt/stress_offline root10.0.0.8:/opt/-r 表示递归复制整个目录。拷完之后先做一次校验防止传输过程丢包md5sum /opt/stress_offline/*.rpm和源机器上的 md5sum 输出逐项对比确保 rpm 包完整。离线环境里 rpm 包损坏导致安装失败的案例不少别在传输这一步省事。3. 离线安装 stress 的完整操作RPM 与源码编译两条路线3.1 RPM 方式rpm -ivh 的依赖顺序与执行拿到离线包目录后安装顺序有讲究。如果只有 stress 一个 rpm目标机器基础库又齐全直接装rpm -ivh stress-1.0.4-16.el7.x86_64.rpm正常情况终端会输出 Preparing... 和 Installing... 两行随后返回。如果想确认安装的细节可以用 rpm -qi 查看软件信息rpm -qi stress输出里会有 Name、Version、Install Date 等字段Version 显示 1.0.4 就能确认装对版本。如果直接安装出现缺依赖的报错说明基础库不完整比如 libgcc 缺失。这时不要硬装把离线目录里的依赖 rpm 按顺序装掉。用 repotrack 拉下来的目录是完整的可以改用 yum localinstall 让 yum 自动处理依赖关系cd /opt/stress_offline yum localinstall -y *.rpmlocalinstall 会优先从本地目录中寻找依赖不会访问网络远程源这正是离线场景需要的。注意这里的 *.rpm 通配符必须保证目录里没有无关 rpm 包否则可能装出问题。安装完成后用 which stress 确认可执行文件位置再用验证步骤跑一遍短压确认工具真的可用。这里有个习惯我一直保持安装任何软件后第一件事是确认可执行文件路径和版本避免出现装完没生效的假象。rpm 方式的优势是后续可以用 rpm -e stress 干净卸载这也是我优先选择 rpm 的核心原因。3.2 源码编译方式configure、make、make install 全流程rpm 包找不到的时候源码编译是兜底方案。以 stress 1.0.4 的源码包为例在有网机器上下载 stress-1.0.4.tar.gz传到目标机器后按顺序执行tar -zxvf stress-1.0.4.tar.gz cd stress-1.0.4 ./configure make make installconfigure 脚本会检查系统环境并生成 Makefilemake 负责编译make install 默认把二进制装到 /usr/local/bin 下。参数上不需要额外调整stress 的默认行为对大多数压测场景足够。如果 configure 阶段报错最常见的原因是目标机器缺少 gcc 或 make这时要么用 rpm 方式补装基础工具要么回到第 2 章把 gcc、make 的 rpm 一并离线下好。源码编译的好处是绕开 el7/el8 不通用的问题编译产物是针对当前系统环境的跨版本兼容坏处是编译过程对系统环境有要求且装完的文件不在 rpm 数据库里后续卸载只能手动删文件。如果希望控制安装位置可以在 configure 时指定 --prefix/usr/local/stress这样所有文件都会集中在这个目录卸载时直接删目录即可。实际装的时候make install 执行完后建议跑一下 find /usr/local/bin -name stress* 确认二进制落位再进入验证环节。3.3 安装后的验证version 检查与短压测试安装完成不等于可用尤其是离线环境工具装没装对要先验证。第一步是版本检查stress --version能打印版本号说明二进制能运行。第二步是确认可执行文件在 PATH 里which stress如果 which 没有输出说明 /usr/local/bin 不在 PATH 里需要补充 export PATH/usr/local/bin:$PATH这样后续调用不用写全路径。第三步是跑一个 10 秒的短压确认负载真实产生stress -c 2 -t 10配合另一个终端执行 uptime观察 load average 是否升高。如果短压正常说明整个工具链可用后面正式压测才可信。我见过有人装完不做验证直接跑长压压完才发现 stress 压根没起来白白浪费几个小时。这个习惯后来越来越值钱特别是在离线环境里出现诡异问题时的排查范围会被大大缩小。4. stress 压测实战与参数详解CPU、内存、IO、磁盘四类负载4.1 核心参数速查表stress 的参数不多但混淆起来成本很高。先把常用参数整理成一张表参数含义示例-c N产生 N 个 CPU 负载进程反复计算平方根stress -c 4-m N产生 N 个内存负载进程默认每个进程 256MBstress -m 2--vm-bytes B每个内存进程分配的内存字节数stress -m 2 --vm-bytes 512M-i N产生 N 个 IO 负载进程反复调用 syncstress -i 4-d N产生 N 个磁盘负载进程反复 write 和 unlinkstress -d 2--hdd-bytes B每个磁盘进程写入的文件大小stress -d 2 --hdd-bytes 1G-t S压测持续时间单位秒stress -c 4 -t 60--verbose输出详细运行过程stress -c 2 -t 10 --verbose参数组合的设计思路一般是先定压测维度再定并发进程数最后定时长。比如 CPU 压测关注的是核数对应关系内存压测关注的是字节数对应系统剩余内存IO 压测关注的是 sync 频率是否触发 iowait。还有一个容易忽略的细节stress 默认不限时长会一直跑因此任何压测命令都建议显式加 -t哪怕只跑几秒也要给自己留一个退出保险。4.2 CPU 压测-c 结合 uptime 判断负载CPU 压测是压测场景里最常见的需求。比如给 4 核服务器加压跑满所有核命令是stress -c 4 -t 120这条命令产生 4 个 CPU 负载进程每个进程持续做平方根运算把对应核心占满持续 120 秒。执行期间建议另开一个终端观察系统状态uptimeuptime 输出的 load average 三个数分别代表过去 1 分钟、5 分钟、15 分钟的平均负载。4 核机器跑满的话load average 会接近 4 甚至略高这是判断压力是否生效最直观的指标。如果压了 2 核但 load average 只有 1.5说明压力进程没有吃满核心原因可能是进程被 cgroup 或 cpu quota 限制这时候要检查 /sys/fs/cgroup/cpu 的 cpu.cfs_quota_us 配置。想更精细地看单核状态可以用 mpstat -P ALL 1观察每个核心的 %usr 是否接近 100%。CPU 压测要控制时长压满全核会让业务进程响应变慢生产环境建议从 1 到 2 核开始试探确认不影响线上服务再逐步加核。load average 的回落速度同样值得观察一般 stress 结束后 1 到 2 分钟内会回到正常水平如果长时间高居不下说明系统里还有其他负载进程在跑。实际压测中经常需要模拟混合负载比如 CPU 和内存同时加压stress -c 4 -m 2 --vm-bytes 256M -t 120这种组合方式更接近真实业务场景比如带数据库的 Web 服务既吃 CPU 又吃内存。组合压测的参数设计原则是每个维度都从单维度压测的 50% 起步观察系统整体表现后再调整不要一上来就拉满。4.3 内存压测-m、--vm-bytes 与内存余量的平衡内存压测的套路是制造内存分配压力让系统接近内存上限从而观察服务在内存紧张时的表现。基本命令stress -m 2 --vm-bytes 512M -t 60意思是启动 2 个内存负载进程每个进程分配并持续占用 512MB总共占用 1GB持续 60 秒。执行前先用 free -h 看内存现状free -h重点看 available 一列压测内存量控制在 available 的一半以内比较安全。如果服务器物理内存 2G已经用了 1.5G你再压 1G系统会直接触发 OOM killer把某些进程杀掉严重时连 ssh 都连不上。OOM 发生后的日志会在 /var/log/messages 里留下 kernel: Out of memory 的记录排查时可以去翻。另外--vm-bytes 的默认单位是字节直接写数字容易算错通常我会用 512M、1G 这种带单位写法。提示--vm-bytes 指定字节数时单位可以写 M 或 G不要写小写 m否则会被当作字节数解析。内存压测时如果想观察分配是否生效可以配合 vmstat 1 看 si 和 so 两列如果换入换出持续非零说明系统内存已经吃紧压测效果达到预期这时候要思考是否该降参数而不是继续往上加。4.4 IO 与磁盘压测-i 和 -d 的本质区别IO 压测用来模拟大量系统调用请求命令是stress -i 4 -t 60它的表现是每个负载进程疯狂调用 sync把 CPU 的 waiowait拉高。配合 vmstat 1 观察能看到 wa 列明显上升。但要注意-i 不一定产生真实磁盘写入如果磁盘是 SSD 并且写入缓存很大可能看到 wa 没有变化这是正常的不代表压测没生效。磁盘压测要走 -d 参数cd /tmp stress -d 2 --hdd-bytes 1G -t 60这会启动 2 个磁盘负载进程每个进程反复创建文件、写入 1G、删除文件循环往复。执行时用 iostat -x 1 观察磁盘利用率iostat 是 sysstat 包提供的没有的话先 yum install -y sysstat。观察重点有两个util 接近 100% 说明磁盘繁忙w_await 明显升高说明写延迟变大。如果 iostat 没有输出说明 sysstat 没装好或者当前用户没有权限读取磁盘统计。执行 -d 压测时stress 会在当前工作目录直接创建文件所以先进入 /tmp 再执行避免在业务目录里留下大量临时文件压测结束后检查 /tmp 下是否有残留的 stress 文件并清理。需要提醒的是-d 压测对磁盘寿命有影响机械盘和部分 SSD 在高强度反复写入下损耗明显不建议长时间压测一般验证几分钟即可。生产环境的磁盘压测最好提前和业务方确认避免压出坏道或者触发磁盘阵列的重建流程。IO 压测还有一个容易误用的地方很多人为了模拟数据库读写直接用 -d 跑文件写入但 stress 的写文件模式是 create-write-unlink 循环和真实数据库的随机读写差别很大结果只能作为粗略参考。5. 避坑指南离线安装与压测中的五个常见问题5.1 安装报错依赖缺失导致 rpm 安装失败现象执行 rpm -ivh 时终端直接报 error: Failed dependencies并列出找不到的库文件。原因目标机器缺少 stress 运行所需的某个基础库或离线目录里的依赖包没有全部就位本质是第 2 章准备阶段漏了依赖。解决用 repotrack 重新拉取完整依赖把整个目录拷进去后改用 yum localinstall让 yum 自动解析本地依赖。如果还缺就在有网机器上按报错信息逐个用 yumdownloader 拉对应 rpm。这个问题的根源在于人眼判断依赖树不可靠少一个子依赖都会失败repotrack 比手工逐个下载靠谱得多。5.2 编译报错configure 阶段找不到 gcc 或 make现象源码编译执行 ./configure 时报错提示 C compiler cannot create executables或者 make 时提示 command not found。原因目标机器是最小化安装没有装 Development Tools 组gcc 和 make 都不存在源码编译自然进行不下去。解决优先考虑 rpm 安装而不是坚持编译如果必须编译把 gcc、make 及其相关依赖 rpm 离线拉过去装好再重新 configure。进入 configure 前先执行 gcc --version 和 make --version 确认工具存在再继续避免在错误的环境上反复尝试。最小化安装的系统连 tar 的版本可能都偏老如果解压源码包时报错可以先检查 tar --version 是否正常。5.3 压测翻车stress -m 把服务器跑死了现象执行 stress -m 2 --vm-bytes 2G 后很快服务器无响应ssh 连接超时控制台显示系统内存耗尽。原因压测内存总量超过物理内存和 swap 的剩余空间系统触发 OOM把关键进程如 sshd 或业务进程 kill 了。解决先 free -h 确认可用内存压测量控制在 available 的一半以内同时给压测命令加 -t 限制时长避免忘记清理。更稳的办法是先小内存试运行比如 --vm-bytes 256M观察系统表现稳定后再逐步加大。这条是我用血泪经验换来的现在每次压内存我都强制先看内存余量再决定参数。5.4 压测失真CPU 占满了但业务响应没变化现象stress -c 8 跑起来top 显示 8 个进程都是 100%但业务接口响应时间几乎没有变化看起来压力白压了。原因一是负载进程被 cgroup 的 cpu 限制只占满了 quota 允许的部分二是压测机 CPU 核数很多8 个计算进程虽然占满单核但总体 CPU 利用率并不高。解决压测前用 lscpu 确认核数压测中配合 top 看总 CPU 空闲百分比确认 %Cpu 的 us 列接近 100% 才算压透。如果被 cgroup 限制检查 /sys/fs/cgroup/cpu 下的 cpu.cfs_quota_us 和 cpu.cfs_period_us 配置。压力测试讲究可复现参数记录和系统状态截图要同步留档不然压出来的数据没法解释。还有一个常见干扰项crontab 里如果有其他定时任务压测结果会和它叠加复盘时很难分离出 stress 的真实贡献。5.5 压测不退timeout 到了但 stress 进程残留现象执行 stress -c 4 -t 30 后等了 30 秒终端应该返回提示信息但实际上负载还在top 里能看到 stress 子进程继续跑。原因stress 主进程收到超时信号后某些子进程没有正确退出或者主进程被 nohup、后台方式启动导致信号传递链条断裂。解决用 pkill -9 stress 强制清理并配合 ps aux | grep stress 确认进程消失。更推荐的姿势是用 timeout 命令包裹比如 timeout 60 stress -c 4确保超时后由内核强制终止整个进程组。压测结束后养成检查进程列表的习惯防止残留进程一直占用 CPU影响后续业务。检查命令可以合并成一条ps aux | grep stress | grep -v grep如果输出为空说明清理干净如果还有进程就继续 pkill。残留进程在离线环境里特别容易引发连锁问题比如影响其他压测任务的结果或者让业务方误以为线上有异常负载。6. 压测后的结果验证与监控技巧用 vmstat 与 uptime 交叉确认压测结束不代表工作结束结果验证才是判断压测是否有效的关键环节。我习惯用两个 linux 常用命令交叉确认uptime 看负载趋势vmstat 看资源消耗明细。跑完一轮压测后先看 uptime 的 load average 三个数值1 分钟和 5 分钟数值都高于压测前说明压力确实作用在系统上15 分钟数值慢慢回落说明系统在恢复。再用 vmstat 1 5 看几秒内的数据vmstat 1 5关注 r 列表示运行队列中的进程数、wa 列表示 IO 等待占比、si 和 so 表示换入换出。CPU 压测后如果 r 列持续高于核数说明负载确实堆积内存压测后 si 和 so 持续非零说明物理内存不足开始使用 swap需要优化压测参数或扩容磁盘压测后 wa 列升高配合 iostat -x 1 能看清是哪个盘在忙。我习惯把每次压测的关键数据记成一行日志格式是时间、压测命令、uptime 三个数、vmstat 的 r/wa这样事后做对比非常方便。有一次线上服务出现周期性卡顿就是靠这个日志反推出来是 crontab 里有个脚本在整点自动跑了 stress -c 2负载叠加导致业务抖动。从那以后我在离线机器上部署完 stress都会把压测命令和留存日志的规则一起固化到操作文档里并且每次压测前先跑一遍 stress --version 和 10 秒短压确认工具真的可用再上长时间压测避免又出现压完才发现工具没起来的尴尬。希望这条习惯能帮到你离线压测这个场景细心比技术更值钱。本文还有配套的精品资源点击获取