简介面向CentOS/Linux运维与性能测试人员这份离线安装包用于在无外网环境中部署stress压力测试工具并附带sar命令相关组件解决内网或隔离网络环境下压测工具缺失、依赖包难获取的问题适用服务器稳定性验证、容量规划和性能基准测试。压缩包为gz格式约46.66MB共43个文件其中11个rpm包为核心另含配置脚本、Makefile工程文件、Texinfo文档、更新日志、安装脚本等既支持rpm直接安装也可基于源码离线编译。内置stress-1.0.4完整资源以及gcc-g等编译依赖包用户无需访问外网即可完成部署配套sar命令可在压测过程中同步监控CPU、内存、磁盘I/O等关键指标帮助运维人员准确评估系统承载能力与瓶颈。已有2592人学习下载对需要在内网环境快速搭建压测平台、开展性能评估并保留监控数据的一线运维工程师具有直接可操作的参考价值。1. Linux CentOS 压力测试为什么我最后选了 stress 离线安装接手过内网服务器的人都有这种体验系统装好功能验证完接下来就是压测。CPU 能不能跑满、内存分配有没有边界、IO 密集下会不会卡死这些问题不压一遍根本不敢交付。可内网没有外网源yum install stress 直接卡在「没有可用软件包」这才是最尴尬的。stress 本身是个很小的工具但它解决的恰好是 CentOS 离线场景下最刚需的一件事——用可控的方式给服务器施加 CPU、内存和 IO 负载而且能精确指定压力大小和时间。你不需要像 sysbench 那样准备复杂的测试数据也不需要写一堆自定义脚本一条命令就能把机器压到某个负载水平。这篇笔记按一条可复现的路径走离线安装怎么准备 rpm 包、参数怎么设、哪些坑会翻车、压测结果怎么判断。照着走一遍你也能在内网环境把压力测试这件事落地。2. 离线安装前的准备依赖分析、rpm 包收集与本地源搭建2.1 为什么用 rpm 包而不是源码编译很多人第一反应是源码编译下载 stress 的 tar.gz然后在目标机器上 ./configure make make install。思路没错但在离线环境里这是给自己找麻烦——编译需要 gcc、make、autoconf 这些工具链生产内网机器上大概率没有你还得把这些依赖的 rpm 包一起收集齐体积大不说装 gcc 本身又可能拖出一堆开发库依赖。我一般用的是 rpm 包方案。stress 的 rpm 包依赖非常干净在 CentOS 7 上只需要 libc 和 libgcc 这类基础库而这些系统自带真正做离线迁移时只需要把 stress 本体和一个可选插件包放一起就行。另一个好处是卸载干净。rpm -e stress 一条命令就没了不会像编译安装那样把二进制散在 /usr/local/bin 和其他目录里交付给运维同事时也方便交接。2.2 在一台有网的机器上收集 rpm 包既然目标机器离线那就在同架构、同版本的联网机器上把包抓齐。我这里用最常见的 CentOS 7 做示例。# 在联网机器上执行先安装 yum-utils 工具集 yum install -y yum-utils # 下载 stress 及全部依赖到指定目录 yumdownloader --resolve --destdir /tmp/stress-rpms stress # 检查下载结果 ls -l /tmp/stress-rpms/yumdownloader 的 --resolve 参数是关键它会把 stress 依赖的所有 rpm 包一并抓下来不会漏。执行完之后目录里除了 stress 本体还会出现 epel-release 之类的依赖如果源里没启用 epel会提示找不到软件包此时先 yum install epel-release 再重试。2.3 目标机器上搭建本地源完成安装把 /tmp/stress-rpms 目录整个拷贝到离线机器的 /opt/stress-rpms用 U 盘、内网传输工具都行。接下来的安装方式有两种。第一种是直接 rpm 安装适合只有一个包的场景# 在目标机器上执行 rpm -ivh /opt/stress-rpms/stress-*.rpm # 验证安装 which stress stress --version第二种是搭本地 yum 源适合后续还要在这台机器上装其他软件的场景。搭源的好处是 yum 能自动处理依赖以后离线装别的包也能复用这个源。步骤是先用 createrepo 生成仓库元数据再写一个 repo 文件指向本地目录。# 目标机器上执行 yum install -y createrepo createrepo /opt/stress-rpms # 写一个本地源配置 cat /etc/yum.repos.d/local.repo EOF [local-rpms] nameLocal RPMs baseurlfile:///opt/stress-rpms enabled1 gpgcheck0 EOF # 清理缓存并确认 stress 可见 yum clean all yum list stress这里解释一下配置里的参数baseurl 指向 file:// 本地路径gpgcheck0 是跳过 GPG 签名校验因为内网源都是自己人维护的。如果后续收集的包多了重新执行 createrepo 就行增量包会自动合并进元数据。需要注意一个细节目标机器的 CentOS 版本需要和收集 rpm 那台机器一致或接近。我在 CentOS 7.6 上收集的包装到 CentOS 7.9 上完全没有问题但要是拿到 CentOS 8 或者 stream 上装libc 版本就可能对不上装的时候会报依赖冲突。3. 让服务器在极限负载下跑起来stress 参数详解与压测实战3.1 参数速查每个参数控制什么stress 的参数不复杂但有几个容易搞混的我用一个表说清楚参数作用典型值注意事项-c, --cpu派生 N 个进程反复执行 sqrt() 运算CPU 逻辑核数超线程机器用逻辑核数不是物理核数-m, --vm派生 N 个进程持续分配和释放内存总内存的 60%-70% 除以单进程内存搭配 --vm-bytes 使用否则默认分配 256MB--vm-bytes指定每个 vm 进程分配的内存大小256M、1G不要超过物理内存否则触发 swap--vm-hang每个 vm 进程分配内存后睡眠 N 秒再释放10s 或 30s想让内存占用稳定就不加想间歇性占用就加-d, --disk派生 N 个进程写临时文件1 或 2写满后删除再重写IO 负载持续存在--hdd-bytesdisk 进程每次写入的临时文件大小1G、2G越大越容易暴露 IO 瓶颈-t, --timeout压测总时长超时自动结束10s、60s、10m强烈建议每次都带上防止压测失控-v, --verbose输出每个进程的启动和结束信息-v定位问题时开启平时关掉避免日志刷屏这个表是我自己压测时精简出来的。核心逻辑就是-c 管 CPU、-m 和 --vm-bytes 管内存、-d 和 --hdd-bytes 管磁盘-t 管总时长。3.2 单场景压测CPU、内存、IO 分别怎么测先把三个维度的单场景压测跑通。CPU 压测最常见的问题是核数估错导致负载拉不上去。# 场景一CPU 压测让 4 个逻辑核跑满 60 秒 stress -c 4 -t 60s -v # 场景二内存压测4 个进程各占 1GB 内存 stress -m 4 --vm-bytes 1G -t 60s -v # 场景三磁盘压测1 个进程反复写 2GB 临时文件 stress -d 1 --hdd-bytes 2G -t 60s -vCPU 场景里-c 4 会让系统出现 4 个进程每个进程都在做平方根运算。我一般先看 lscpu 确认逻辑核数然后在「逻辑核数×1.2」的范围内取一个值。比如 4 核 8 线程的机器先压 4 个再压 8 个看负载曲线。内存场景里最容易踩的坑是 --vm-bytes 设太大。4 个进程各 1G物理内存 8G 的机器勉强能扛但内存 4G 的机器直接进入 swap。我建议单进程内存不要超过总内存的 15%4 个进程加起来控制在 60% 左右剩下的留给系统和其他进程。磁盘场景里--hdd-bytes 2G 的意思是每个进程会生成一个 2GB 的临时文件写完删除再写循环往复直到超时。这个场景对机械盘和虚拟化平台的存储后端压力都很大压测时最好同时开两个终端一个跑 stress另一个用 iostat 盯磁盘利用率。3.3 组合负载多维度同时压测真实业务不会只压一个维度——CPU 高负载时内存也在增长IO 高负载时 CPU 也在处理中断。组合压测才更接近线上真实情况。# 组合场景8 核 CPU 6GB 内存 1 个磁盘进程持续 10 分钟 stress -c 8 -m 6 --vm-bytes 1G -d 1 --hdd-bytes 1G -t 10m -v # 组合场景变体带内存释放间隔模拟间歇性峰值 stress -c 8 -m 6 --vm-bytes 1G --vm-hang 30 -d 1 --hdd-bytes 1G -t 10m -v组合压测有一条我自己总结的经验先单场景各跑 30 秒确认每个维度都能正常压起来再组合跑。别上来就一个长命令直接 10 分钟万一某个参数设置不合理比如内存超了物理内存前 30 秒就能把系统拖进濒死状态到时候 OOM Killer 会帮你把压测进程杀掉。--vm-hang 30 这个参数的含义是每个内存进程分配 1GB 后保持占用 30 秒然后释放并重新分配。它模拟的是「内存缓慢增长、定期回落」的业务特征配合 CPU 和磁盘同时压效果更接近真实场景。组合压测还有一个容易被忽略的点内存和磁盘同时压时如果 --hdd-bytes 设置的磁盘文件太大文件系统缓存会吃掉大量内存和 --vm-bytes 抢资源导致内存压测失真。我一般把 --hdd-bytes 控制在 1G 以内宁可让磁盘进程反复写也不让它占住缓存。4. 离线安装与压测避坑五个高频翻车现场4.1 翻车现场一rpm 安装时报依赖缺失现象在目标机器上执行 rpm -ivh stress-*.rpm报 error: Failed dependencies提示缺少某个 lib 库或无法识别的符号。原因收集 rpm 包那台机器的源里启用了某些额外仓库比如 epel而目标机器源里没有这些仓库标记rpm 记录里找不到对应的依赖包记录。或者版本不对比如把 el7 的包拿到 el8 上安装。解决不要在装的时候再去找包。把报缺少的包名记下来回到联网机器上用 yumdownloader --resolve 单独抓那个包拷回目标机器放到同一目录然后重新执行 install。装完后用 rpm -qa | grep stress 确认版本符合预期。4.2 翻车现场二压测进程直接被 OOM Killer 干掉现象stress -m 6 --vm-bytes 1G 跑了一会儿终端报 Killed查看 /var/log/messages 发现 kernel: Out of memory: Kill process。原因--vm-bytes 总和超过了物理内存或者和系统其他进程抢内存时触发了内核的 OOM 机制。尤其是组合压测时磁盘缓存也会占用内存数据更加失控。解决先 free -g 看总内存把 vm-bytes 总和控制在物理内存的 60% 以内。另一个办法是加 --vm-hang让每个内存进程占用一段时间后释放给系统留出呼吸空间。跑压测前最好清一下缓存sync echo 3 /proc/sys/vm/drop_caches。4.3 翻车现场三一把梭 rpm -ivh *.rpm 装到一半报错现象把收集来的十几个 rpm 包全放一起执行 rpm -ivh *.rpm装到某个依赖包时报错后面的包全部中断。原因rpm 本身不处理依赖顺序一条命令装多个包时如果前面的包依赖后面的包而 rpm 没有先装后者就会失败。这个现象在包数量多时特别常见尤其是从不同仓库收集的包混在一起时。解决先用本地源方案createrepo local.repoyum 会自动排序依赖。如果坚持 rpm 直装那用 rpm -Uvh *.rpm --nodeps 的方式我不推荐——它跳过了依赖检查装完后可能运行时报错。我的习惯是少于 5 个包用 rpm -ivh 逐个装多于 5 个就乖乖建本地源。4.4 翻车现场四压测命令跑了负载却拉不满现象stress -c 8 跑起来top 里的 CPU 负载只到 50%怎么加核数都上不去。原因大概率是没搞清楚物理核和逻辑核的区别。比如 4 核 8 线程的机器-c 4 对方根运算的利用程度只有一半因为每个逻辑核分时共享物理核的运算单元。还有可能是机器本身被虚拟化限了 CPU 配额宿主机只给了 4 核的算力你压 8 核也没用。解决先用 lscpu 看 Thread(s) per core 和 Core(s) per socket再用 nproc 看系统实际认的逻辑核数。我一般按逻辑核数的 1.2 到 1.5 倍来压比如 nproc 显示 8就 -c 10 或 -c 12。如果压满后负载还是上不去用 top 按 CPU 排序能看到每个 stress 进程的 CPU% 数值逐个判断是 CPU 配额限制还是参数问题。4.5 翻车现场五压测停了机器还卡了很久现象stress 命令已经正常退出-t 超时到了但系统还是明显卡顿free 显示 swap 占用很高响应慢。原因内存压测过大时一部分数据被交换到了 swap 分区stress 释放内存后系统不会立刻把 swap 里的数据换回物理内存而是由 kswapd 在后台慢慢回收。如果磁盘是机械盘这个过程可能持续几分钟期间机器一直很卡。解决压测结束后做一次内存回收sync echo 3 /proc/sys/vm/drop_caches然后观察 swap 使用率下降。如果频繁做内存压测我建议把 vm.swappiness 调到 10 左右避免系统过早使用 swap具体是往 /etc/sysctl.conf 里加 vm.swappiness10再 sysctl -p。5. 用数据说话压测过程中的监控与结果判定5.1 监控工具选型top、vmstat、iostat 各自看什么压测只跑不看数据等于白压。我的经验是至少开三个终端一个跑 stress或者用 nohup 放后台另外两个盯监控。top 是最直接的看整体负载和单进程 CPU% 是否达标。重点看 us用户态 CPU和 sy内核态 CPU占比正常情况下 us 应该在 90% 以上如果 sy 太高说明系统在内核态做了太多事情可能是锁竞争或者中断风暴。vmstat 适合看内存和 CPU 的全局数据。每秒刷一次能清晰看到内存的 free、si/soswap 换入换出和 r运行队列。r 值一般要小于 CPU 核数如果 r 值飙到核数的两倍以上说明 CPU 不够用了。iostat 则是磁盘场景的必备。重点看 %util设备使用率和 w_await写请求平均等待时间。机械盘 %util 到 90% 以上已经是极限SSD 反而可能 %util 只有 50% 就出现延迟飙升这时候要结合 w_await 判断。5.2 压测成功的判定标准是什么很多人以为压测不报错就是成功其实还要看数据。我一般看三个指标第一负载是否达到预期。比如压 8 核 CPUtop 里应该看到 8 个 stress 进程各占接近 100% CPU整体 CPU ussy 在 95% 以上。如果只有 60%说明没压起来检查核数设置。第二内存压测时 swap 是否明显增长。健康的压测是物理内存占用上升但 swap 不该有太大变化。用 vmstat 看 si/so 列如果持续有换页说明内存超配了要调低 vm-bytes。第三压测结束时系统是否平稳恢复。压测进程退出后top 里的负载应该逐渐回落r 值慢慢降低。如果压测结束后几分钟负载还是很高说明有内存回收或磁盘 flush 在后台运行虽然不一定致命但说明压得有点狠了。做压测记录时我用一个简单的表格每组压测一行方便对比压测场景参数设置CPU us%内存 freeswap si/soIO %util结果CPU 8核-c 8 -t 60s97%稳定0/0低通过内存 6G-m 6 --vm-bytes 1G低下降至 1.2G0/0低通过组合压测-c 8 -m 6 -d 190%下降至 1.5G0/885%建议关注5.3 压测结束后怎么判断机器有没有隐患压测结束后不要立刻走开我习惯多观察几分钟。重点看两个文件/var/log/messages 里有没有 kernel: 开头的错误、dmesg 的输出里有没有硬件相关告警。还有一个是被低估的指标压测前后系统运行时间。如果压测过程中触发过 panic 或 kernel oops系统会自动重启uptime 会归零。我看过有的机器压测 10 分钟后自动重启了日志里什么都没留下最后在 dmesg 里发现是 CPU 温度过高触发了硬件保护——这就不只是 stress 的问题了得考虑散热和 BIOS 设置。6. 进阶把压测固化成脚本一键跑完整套压力验证压测不能每次都是临时敲命令。我把前面这些参数和监控逻辑打包成了一个 bash 脚本跑一遍就能按固定组合完成 CPU、内存、磁盘压测最后输出一段汇总结果。流程是先用 -t 5s 快速验证参数能正常跑再按完整时长执行监控数据用 vmstat 和 top 采样记录下来。#!/bin/bash # 一键压测脚本适用于 CentOS 7 / 8 离线环境 # 用法: ./stress_test.sh [CPU核数] [内存进程数] [内存大小单位M] [压测秒数] CPU$1 VM_PROC$2 VM_SIZE_M$3 DURATION$4 echo [INFO] 压测参数: CPU$CPU, VM进程$VM_PROC, 内存${VM_SIZE_M}M, 时长${DURATION}s # 前置检查确认 stress 已安装 if ! command -v stress /dev/null; then echo [ERROR] stress 未安装请先完成离线安装 exit 1 fi # 快速自检5 秒看参数是否合理 stress -c $CPU -m $VM_PROC --vm-bytes ${VM_SIZE_M}M -t 5s if [ $? -ne 0 ]; then echo [ERROR] 快速自检失败请检查参数 exit 1 fi # 记录压测前内存状态 free -m vmstat 1 3 /tmp/vmstat_before.txt # 正式压测监控数据后台记录 nohup stress -c $CPU -m $VM_PROC --vm-bytes ${VM_SIZE_M}M -d 1 --hdd-bytes 1G -t ${DURATION}s -v /tmp/stress_run.log 21 STRESS_PID$! echo [INFO] 压测进程 PID: $STRESS_PID # 压测期间每 10 秒记录一次内存快照 while kill -0 $STRESS_PID 2/dev/null; do free -m | awk {print strftime(%H:%M:%S), $0} /tmp/mem_snapshot.txt sleep 10 done # 压测结束后输出汇总 echo [INFO] 压测结束查看 /tmp/mem_snapshot.txt 获取内存变化 grep -E Killed|Panic|oom /tmp/stress_run.log echo [ERROR] 压测异常 || echo [SUCCESS] 压测流程正常脚本里的关键设计是自检流程真正时长跑之前先用 5 秒做快速自检参数不对能在 5 秒内暴露出问题而不是等到跑完 10 分钟才发现内存超配。nohup 加 让压测进程在后台跑即使终端断了也不会中断压测配合 while 循环每 10 秒记录一次内存快照压测结束后从文件里能看出内存是从什么水平开始波动的。有次压一台共享宿主机上的虚拟机我按物理机的思路把核数和内存都拉满结果把宿主机上其他几个虚拟机也拖垮了。从那以后我每次压测前都会先看虚拟化标识和系统配额——在别人的共享资源上压测永远要留三分之一余量。这个教训后来帮我在生产环境压测时避免了好几次事故。希望这篇笔记能帮你在内网环境的压测之路少走几步弯路。本文还有配套的精品资源点击获取