Linux CentOS离线安装stress压力测试工具完整指南

简介面向内网隔离环境下的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 21 这里把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运行队列、waIO等待、si和soswap换入换出。压测期间如果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确认一下有残留就手动killpkill -f stress还有一种情况是负载高不是stress导致的而是alarm时钟或者io_wait堆积。这时候配合iostat和vmstat把根源揪出来再针对性处理。8. 我的体会离线安装的底层逻辑是版本管理和依赖预判这次完整走完linux centos stress离线安装的全流程我发现离线安装真正考验的其实是对系统环境和依赖关系的预判能力。只要在联网机器上把依赖梳理清楚然后把包完整地带进内网不管是rpm方式还是源码方式都不会太难。rpm方式强在“留痕”卸载干净源码方式强在“通吃”跨版本适应力更强。至于监控配套工具sysstat套件的离线安装思路和stress完全同构一套方法可以用在无数个其他软件上。最后再分享一个实用的小技巧在联网机器上拉下来的rpm包不要只下载目标软件本身的把依赖包也一并保留目录结构整个目录打成tar包带走。宁可多带几个用不上的也不要到了内网缺个依赖再干瞪眼。这个习惯帮我解决过大大小小几十次离线上线的问题工程上真正的省事往往靠的就是这种前置三分钟的细心。本文还有配套的精品资源点击获取