简介：面向内网隔离环境下的CentOS运维与性能测试人员，这份gz格式的离线安装包将stress-1.0.4压力测试工具及相关依赖集中打包，并包含sar命令的安装组件，解决了无外网时无法通过yum直接安装性能压测工具的问题，适合具备基础Linux操作经验、需要快速完成系统性能验证的中级工程师。包体共43个文件，容量约46.66MB，主要涵盖rpm安装包、configure配置脚本、Makefile模板、texi说明文档与C源码，既能直接安装预编译rpm，也支持从源码自行编译，便于适配不同系统版本。考虑到离线环境常遇到编译器缺失，包内准备了编译工具链相关rpm，可减少逐个查找依赖的时间。已有2573人学习下载，对在隔离网络中搭建Linux压测环境的工程师而言，这套资料能帮助快速完成stress与sar的部署，并借助包内文档理解参数用法和排查常见安装问题。整个包内文件组织清晰，安装或编译前只需简单核对系统版本，即可复用同一套离线包完成多次部署。 搞Linux运维这些年，最怕听到的就是“机器在内网，不能上外网”这几个字。特别是像linux centos stress离线安装这种需求，正常情况下一条yum install stress的事，到了隔离环境里，就得老老实实走离线流程。前阵子帮一个客户排查生产环境性能瓶颈，需要在无外网的CentOS 7.9服务器上跑压力测试，正好完整走了一遍离线安装stress工具的流程，顺便把压测期间要看CPU、内存、IO状态的那套配套工具也一并解决了。这篇文章就把整个思路、具体操作和踩过的坑整理出来，给同样被离线环境折腾过的朋友一个参考。
1. 为什么要折腾离线安装，以及装之前必须搞清楚的事
1.1 离线安装不是“下载个包传上去”那么简单
很多人觉得离线安装就是把安装包下载好，然后用U盘拷贝到服务器上，解压、安装、完事。实际干过的人都知道，这里面有个大坑叫依赖关系。CentOS的软件包管理器在设计时就默认“联网可用”，yum在安装一个包时会把依赖树上的所有包一并拉下来。一旦离线，yum没法自动解决依赖，只能靠人肉梳理。
以stress为例，它的依赖非常简单，几乎只需要libc和glibc这些基础库，这些在minimal版系统里都自带。但如果你图省事去网上随便找个rpm包，可能会遇到rpm依赖报错，比如缺少libstdc++.so.6或者版本不匹配之类的。而如果走源码编译的方式，只要系统里有gcc、make和基础开发工具，基本就能一路编译过去，反而更省心。
我在这次实践中最终选择了源码编译，原因很简单：rpm包需要根据CentOS版本和架构找对应的包，而源码方式几乎无视系统小版本差异，只要有编译环境就能过。
1.2 动手前先摸清系统的底细
不管用什么方式安装，第一步永远是确认环境信息。我习惯先执行这几条命令，把家底盘清楚：
cat /etc/redhat-release # 查看CentOS具体版本 uname -m # 查看系统架构，x86_64还是aarch64 gcc --version # 检查是否已安装gcc make --version # 检查是否已安装make为什么这些信息重要？因为不同架构对应的包不一样，x86_64的rpm包放到ARM服务器上装不了。至于gcc和make，这是源码编译的刚需，没有的话还得先想办法装这俩工具。
提示：CentOS 7自带的gcc版本通常是4.8.5，编译stress完全够用。如果你遇到的是CentOS Stream、CentOS 8/9这类新版本，同样适用，它们自带的gcc版本更高，反而更友好。
1.3 一台能联网的“同款”机器是最大底牌
离线安装最理想的准备方式，不是去网盘乱找资源，而是在一台能联网、系统版本和架构与目标机一致的机器上，用yum把依赖包全部下载下来，再拷到内网去装。
具体做法是这样的：
# 在联网机器上执行，仅下载不安装 yum install --downloadonly --downloaddir=/root/stress_rpm stress这个--downloaddir参数会把stress及所有依赖的rpm包全部下载到指定目录。如果没有yum-downloadonly插件，CentOS 7自带的yum多数版本已经支持这个参数了，不需要额外安装插件。下载完成后，把整个目录打包拷到内网机器上，执行：
rpm -Uvh /root/stress_rpm/*.rpm这个方法的好处是rpm数据库会完整记录stress的安装信息，后续卸载、查询都方便。但前提是联网机器和目标机器的系统版本、架构必须基本一致，否则依赖包版本可能对不上，装了容易出幺蛾子。
2. 方案选型：rpm离线包、源码编译、容器镜像三条路怎么选
2.1 三种主流离线安装方案对比
我在实际操作中梳理过三种linux centos stress离线安装的可行路线，各有优劣，直接看对比表：
| 方案 | 前置条件 | 优点 | 缺点 |
|---|---|---|---|
| rpm包离线安装 | 需一台联网同版本机器，或用yumdownloader工具 | 安装快，rpm数据库有记录，卸载方便 | 依赖关系需要人肉确认，版本匹配要求高 |
| 源码编译安装 | 系统需有gcc、make | 通用性强，不挑版本，可控性高 | 编译耗时，不产生rpm记录，卸载需手动删文件 |
| 容器镜像方式 | 内网有容器镜像仓库 | 环境隔离，不污染宿主机 | 需要dockers环境，压测工具本身很小，有点大材小用 |
2.2 为什么我最终选了源码编译这条路
说实话，rpm方式确实是很多运维的首选，但如果遇到“目标机器没有gcc，而我又不想先把gcc那堆开发包传进去”的场景，rpm方式就会陷入死锁。而stress的源码包非常小巧，整个项目就是几个C文件，编译流程简单直接，对gcc版本几乎不挑。
另外还有一个现实原因：很多内网服务器的操作系统已经做过了安全加固，或者被纳管工具管控，随意rpm安装可能触发合规告警，而源码方式把二进制放到/usr/local/bin下，不触碰系统包管理器，反而更“低调”。当然，这只代表我个人的处理偏好，正规受管环境还是遵循单位的变更流程来。
源码编译对后续维护也比较友好。压测工具这种小软件，升级频率不高，需要更新时重新编译覆盖即可，不用操心rpm依赖是否会被误删。
2.3 不管选那哪种方案，压测时还得看这些状态
这里有个容易忽略的细节。很多人听说stress是压测工具，就以为装了它就能看到漂亮的结果报告。实际上stress只负责制造压力，不负责展示指标。要看CPU、GPU、内存、IO各种状态，必须配合性能监控工具，比如top、mpstat、free、iostat这些系统自带的命令，或者额外安装sysstat套件。
而sysstat套件在离线环境下又是另一个坑——它通常不在minimal版的默认安装里，需要额外处理。这个我在后面专门的章节会讲，先记着这个关联性就行。
3. 源码编译安装stress的完整实操记录
3.1 下载源码包和准备编译环境
stress的源码在SourceForge和GitHub上都有，我这里以常见的stress-1.0.4版本为例。下载文件就是一个stress-1.0.4.tar.gz，大小只有几十KB，传起来非常轻松。
在联网机器上下载好之后，用U盘、SCP、堡垒机文件传输等方式把tar包传到内网服务器，放在/usr/local/src目录下。接下来解压并进入源码目录：
cd /usr/local/src tar xzf stress-1.0.4.tar.gz cd stress-1.0.4在编译之前，先确认gcc和make存在。如果没有，看是否能用系统安装光盘中的rpm包含有的gcc包来安装，或者用挂载CentOS安装ISO的方式配置本地yum源。这里我提前做了准备，在联网机器上把gcc、make及其依赖全部离线打包，一并带了进去。
3.2 经典三步走：configure、make、make install
这个流程是Linux源码安装的通用套路，stress也不例外。每一步的作用我简单说一下：
./configure make make install第一步./configure会检查系统编译环境和依赖库，生成Makefile。它主要做两件事：检测有没有gcc、检测头文件和库文件的位置，并把安装路径等参数写好。默认安装路径是/usr/local/bin，如果你想改到别的路径，可以用--prefix参数指定。
第二步make是真正执行编译。它会根据生成的Makefile，把C源文件编译成可执行文件。这一步如果系统资源紧张，会慢一点，但stress这么小的项目，通常一两分钟就完事。如果想加速，可以加-j4参数，比如make -j4，用4个核心并行编译。
第三步make install是把编译好的二进制文件安装到系统路径。安装完成后，验证一下：
stress --version如果能输出版本号，就说明安装成功了。如果提示找不到命令，多半是/usr/local/bin这个目录不在PATH环境变量里，手动加一下就行。
3.3 一条龙验证：先小规模压一下
我习惯在正式压测前先做一次小规模验证，确认stress能正常工作。比如先压一个CPU核心，持续5秒：
stress --cpu 1 --timeout 5s执行期间另开一个终端，用top看CPU使用率，正常情况下能看到一个进程把单个核心跑到接近100%。如果这里一切正常，说明stress本体没有问题了，接下来就可以设计正式的压测场景。
注意：stress会让系统负载迅速升高，在没有监控告警兜底的情况下，不要一上来就全核心压制，否则SSH操作都会卡顿。先小规模试探，确认行为符合预期，再放开跑。
4. 用stress做压力测试的核心手法和参数解析
4.1 stress的四大压力类型
stress可以制造四类系统压力：CPU计算压力、内存分配压力、IO同步压力、磁盘写压力。对应关系如下：
| 压力类型 | 参数 | 实际效果 |
|---|---|---|
| CPU压力 | -c N或--cpu N | 生成N个进程做无限循环的平方根运算，把CPU跑满 |
| 内存压力 | -m N或--vm N | 生成N个进程，持续分配和释放内存 |
| IO压力 | -i N或--io N | 生成N个进程，不断调用sync()系统调用，制造IO等待 |
| 硬盘压力 | -d N或--hdd N | 生成N个进程，持续写入临时文件，测试磁盘写能力 |
其中CPU压力最简单也最常用。比如我这次排查瓶颈，第一步就是确认这台机器到底能扛住多少并发，直接用stress -c 8 --timeout 60s把8个核心全部压满，然后观察系统响应情况。
4.2 压测时的常见组合参数
单独压一种负载往往不够，压测的意义在于模拟近似的实际情况。比如一台Web服务器，它同时要处理请求（CPU密集）和缓存数据（内存密集），那就需要混合压测。
# 8个CPU压力进程 + 2个内存压力进程，各分配512MB内存，持续时间10分钟 stress --cpu 8 --vm 2 --vm-bytes 512M --timeout 600s参数--vm-bytes是每个内存压力进程分配的内存大小，--timeout是自动停止时间。我一般习惯加上--timeout，防止忘记结束压测导致服务器长时间满载。当然，正式压测有专门的时间规划，不用强制加，但新手强烈建议加上。
还有一个参数容易被忽略，就是--verbose。加上它之后，stress会把每个worker进程的状态变化实时打出来，方便你确认压力是否真的起来了：
stress --cpu 4 --vm 2 --vm-bytes 1G --timeout 120s --verbose4.3 一次完整的压测案例演示
这里用一个典型案例展示完整的压测流程。假设我们要评估一台8核16G的服务器，在CPU和内存双重压力下的稳定性。
第一步：记录压测前的基线数据。
uptime free -h mpstat -P ALL 1 5第二步：启动压测任务，压10分钟，CPU全核加内存6G。
stress --cpu 8 --vm 3 --vm-bytes 2G --timeout 600s --verbose > /tmp/stress_test.log 2>&1 &这里把stress放到后台执行，日志重定向到文件，避免SSH断开导致压测中断。
第三步：在压测期间，周期性地采集系统状态。
# 每5秒采一次，共采60次 pidstat 5 60 > /tmp/pidstat.log iostat -x 5 60 > /tmp/iostat.log vmstat 5 60 > /tmp/vmstat.log第四步：压测结束后，对比压测前后数据，看系统是否出现异常。如果压测期间CPU能够稳定在合理利用率、内存没有触发OOM Killer、系统load average没有异常飙升，就可以认为服务器扛住了当前压力等级。
5. 压测时查看CPU、GPU、内存、IO状态的方法
5.1 CPU和内存的最快查看方式：top与命令组合
很多人习惯用sar或top来看CPU状态，因为压测时最直观的变化就是CPU使用率和内存占用。
先说top。执行top命令后，按1键可以展开每个CPU核心的使用率，能清楚看到每个核心是否被跑满。load average一栏反映的是系统整体负载，如果这个数值长时间超过CPU核心数的两倍，说明系统已经严重过载。
内存部分用free -h，它把系统的总内存、已用、可用内存梳理得一目了然。不过在看内存时不要只看used列，还要关注available列，这个才是真正可分配给新进程的内存余量。压测内存如果分配过大，available接近0，系统可能触发OOM Killer，直接把压测进程杀掉，甚至把业务进程也殃及池鱼。
5.2 单核维度监控用mpstat和pidstat
如果想知道压力是不是均匀地打到了每个CPU核心上，用mpstat比top更精准。它是sysstat套件里的工具，执行mpstat -P ALL 1会按每秒间隔刷新每个核心的使用率，哪颗核被压满了、哪颗还在闲置，一目了然。
pidstat则适合观察进程级别的资源占用。比如我想确认stress生成的8个CPU worker进程是否都吃满了CPU，可以执行：
pidstat -u 1 5输出会显示每个进程的CPU使用率、进程号、命令名。通过对照stress进程的PID，可以精确确认压力任务是否正常在跑。
5.3 GPU环境下的监控思路
如果你的压测场景涉及GPU，比如跑深度学习推理、图形渲染，那要看的东西就不一样了。首先确认有没有GPU工具包，nvidia-smi是NVIDIA显卡的标配工具，可以实时查看GPU型号、显存占用、温度和利用率。执行nvidia-smi -l 1可以让它每秒刷新一次。
如果没有NVIDIA工具包，那就看CPU与内存状态来间接判断。因为GPU任务通常伴随着CPU调度和内存copy，当GPU满载时，CPU和内存的使用率也会同步升高。不过要注意，压力测试工具stress本身不直接压GPU，如果你需要压GPU，得用专门的工具，比如gpu-burn或glmark2，这是另一套离线安装的问题。
5.4 系统级I/O、网络与综合负载监控
IO的查看方式，我一般先用iostat -x 1看各块磁盘的%util列。这个值表示磁盘在工作的时间占比，如果长时间接近100%，说明磁盘已经是瓶颈。
综合负载方面，vmstat 1是个很实用的命令。它输出一长串指标，重点关注r（运行队列）、wa（IO等待）、si和so（swap换入换出）。压测期间如果wa值持续很高，说明磁盘IO跟不上；如果si和so频繁跳动，说明内存不够用，系统已经在疯狂换页了。
把这些工具组合起来，基本可以覆盖压测期间“CPU、GPU、内存、IO各种状态”的全方位监控。
6. 配套工具sysstat套件的离线安装
6.1 sysstat为什么也得离线装
前面反复提到mpstat、iostat、sar，这几个命令都属于sysstat套件。CentOS 7 minimal安装版默认不带这个套件，所以离线环境里还得解决它。
安装方式和stress类似，可以走rpm，也可以走源码。sysstat的源码编译相比stress稍微复杂一些，因为它的源码文件多一些，但它已经在Linux世界里存在几十年，编译体系非常成熟，几乎不会有坑。
6.2 sysstat源码编译的完整步骤
先去官网下载sysstat源码包，比如sysstat-12.7.2.tar.xz。上传到服务器后执行：
cd /usr/local/src tar xf sysstat-12.7.2.tar.xz cd sysstat-12.7.2 ./configure make make install安装完成后，验证一下：
mpstat -V iostat -V sar -V如果各命令都能输出版本号，说明sysstat安装成功。这里有个小细节，默认安装路径同样是/usr/local/bin，如果你的PATH没包含这个目录，就得加上或者用全路径访问。
6.3 sysstat的压缩方式和日志收集
sysstat不仅能实时监控，还能通过sar工具把系统状态写入日志，方便压测结束后分析历史数据。每10分钟采集一次数据并保存到/var/log/sa/目录的功能，对应的是/etc/cron.d/sysstat里的定时任务。
如果你是通过源码方式安装的，这个定时任务不会自动配置，需要手动写一个cron任务。比如：
* * * * * /usr/local/lib/sa/sa1 1 1 5 23 * * * /usr/local/lib/sa/sa2 -A这样系统就会在每次压测前后自动记录状态，等压测结束后用sar -d -f /var/log/sa/saXXX查看历史磁盘数据，比手动记录靠谱得多。
7. 常见问题与排查技巧实录
7.1 configure阶段报错“C compiler cannot create executables”
这个错误是离线安装源码软件时最容易踩的坑，原因是gcc没装好或者缺少必要的头文件。排查方式：
which gcc gcc -v如果gcc确实存在还在报这个错，多半是缺少glibc-devel这个基础开发包。这时候可以试试通过本地ISO镜像或者rpm包的方式，把glibc-devel补装上去。这个包的依赖不少，最好在联网的同版本机器上用yum install --downloadonly --downloaddir=/root/glibc_devel glibc-devel拉取全套依赖，再传进内网安装。
7.2 make阶段报错找不到头文件
make过程中如果提示找不到stdio.h、stdlib.h这类头文件，基本可以断定glibc-devel缺失。在联网机器上提前下载好这个包及其依赖，内网机器执行：
rpm -Uvh /root/glibc_devel/*.rpm装完后重新make clean && make，一般就能通过。
7.3 压测过程中系统卡死怎么办
有一次我在客户机器上压测，直接把所有CPU核心都压满了，结果SSH操作变得非常卡，命令敲半天没反应。原因是CPU全被stress占用，连SSH进程都分不到时间片。
遇到这种情况不要慌，在另一个能访问的终端执行：
killall stress如果连命令都敲不进去，那就等压测的--timeout时间自动结束，或者联系现场人员硬重启。为了避免这种尴尬，我后来都会提前把stress的PID记录下来，或者干脆在nohup启动时把日志写好。更稳妥的做法是给stress的进程设置较低的优先级，比如：
nice -n 19 stress --cpu 8 --timeout 300s这样即使压力拉满，系统管理员的常用命令还是能抢到CPU时间片，不至于完全失联。
7.4 rpm方式安装时提示依赖冲突
如果你选择rpm方式安装，可能会遇到依赖冲突。比如系统里已经有其他软件包自带了libc的某个版本，与stress的rpm包中依赖版本不一致。最直接的解决方式就是放弃rpm，改用源码编译。源码方式几乎不依赖外部库版本，冲突的可能性大大降低。
7.5 压测结束后系统负载仍然很高
stress的进程在压测结束后会自动退出，但如果加了--verbose日志并在后台运行，主进程偶尔会残留。用ps aux | grep stress确认一下，有残留就手动kill：
pkill -f stress还有一种情况是负载高不是stress导致的，而是alarm时钟或者io_wait堆积。这时候配合iostat和vmstat把根源揪出来，再针对性处理。
8. 我的体会：离线安装的底层逻辑是版本管理和依赖预判
这次完整走完linux centos stress离线安装的全流程，我发现离线安装真正考验的其实是对系统环境和依赖关系的预判能力。只要在联网机器上把依赖梳理清楚，然后把包完整地带进内网，不管是rpm方式还是源码方式，都不会太难。rpm方式强在“留痕”，卸载干净；源码方式强在“通吃”，跨版本适应力更强。至于监控配套工具，sysstat套件的离线安装思路和stress完全同构，一套方法可以用在无数个其他软件上。
最后再分享一个实用的小技巧：在联网机器上拉下来的rpm包，不要只下载目标软件本身的，把依赖包也一并保留目录结构，整个目录打成tar包带走。宁可多带几个用不上的，也不要到了内网缺个依赖再干瞪眼。这个习惯帮我解决过大大小小几十次离线上线的问题，工程上真正的省事，往往靠的就是这种前置三分钟的细心。
本文还有配套的精品资源，点击获取
