简介针对CentOS Linux环境的离线压力测试需求这套资源打包了stress-1.0.4工具及其依赖组件面向内网或无外网条件下需要快速搭建性能压测环境的运维工程师和开发人员。资源整体压缩后约46.66MB共43个文件其中以11个rpm软件包为核心便于直接安装同时包含configure、automake等编译配置脚本以及texi格式的说明文档、C语言源码和更新日志等辅助材料可支撑从安装、编译到使用排查的完整流程。值得一提的是包内还附带了sar命令相关附件能够在压测执行过程中同步监控CPU、内存等系统资源占用使压力测试结果更有参考价值。目前该资源已有2592人学习下载离线场景下的实用性和复用率得到了不少使用者验证。通过这份资料读者可以一次获得完整的工具链、依赖包、监控命令与说明文档省去逐个查找收集的麻烦适合作为CentOS服务器压测工具箱的离线补充。1. linux 压力测试工具离线安装一台内网 CentOS 的前前后后有段时间我在某公司维护一批不能连外网的 CentOS 服务器业务方要做上线前的容量评估需要跑一次标准的 linux 压力测试。我习惯性地执行yum install stress结果自然是失败——没有可用的网络源。更麻烦的是服务器上连 gcc 和 make 都没装全想临时编译个工具都无从下手。那次折腾了大半天最后才走通了一条“离线安装 stress”的完整路径。后来我把步骤整理成了笔记之后再有新机器要压测照着走一遍就能跑通。这篇文章就是给同样卡在“内网怎么装 stress、怎么验证压测有效”的人准备的新手可以照着一步步做老手也能看看我踩过的几个坑。2. 环境准备与版本选择搞清楚你要装哪个 stress2.1 先给服务器做一次体检离线安装的第一步不是找安装包而是确认这台 CentOS 到底是什么版本、缺什么基础环境。我吃过亏在 CentOS 7 上装了一个用 glibc 2.28 编译的 stress 二进制结果报versionGLIBC_2.28 not found因为系统里的 glibc 还是 2.17。所以先跑一遍下面的命令把系统信息记下来cat /etc/redhat-release uname -r rpm -q glibc这三条命令分别输出系统版本、内核版本、glibc 版本。CentOS 7 默认 glibc 是 2.17CentOS 8/9 会更高。这个参数决定了你能直接用别人编译好的二进制还是必须自己源码编译。接下来再确认有没有安装基础编译工具which gcc which make which rpmbuild如果which gcc和which make都没有输出说明这台机器连编译环境都不完整。这时候你只有两条路要么在联网的机器上把 gcc、make 的 rpm 包也一起抓下来带进去要么找一个在同样 glibc 版本下编译好的 stress 静态二进制。我更推荐前者因为静态二进制有时候会在运行时行为上有些微妙差异而且后续如果还想装其他压测工具编译环境早晚要用到。2.2 stress 版本怎么选stress 这个工具本身很轻量官方最新版本一直停留在 1.0.51.0.4 也很常见。两个版本核心功能基本一样但 1.0.5 修复了一些在 64 位系统上对内存限制的检测问题。如果你要压测 4GB 以上的内存建议直接找 1.0.5要是只有 1GB-2GB 内存的小机器1.0.4 也足够用。不过我的习惯是统一装 1.0.5省得后续因为版本差异被质疑测试结果。除了源码也有人把 stress 打包成了 rpm。比如 EPEL 源里有stress这个包版本就是 1.0.4。但内网机器一般没有 EPEL 源所以最可靠的做法是在能联网的机器上把 stress 的 rpm 包连同依赖一起下载好然后用 U 盘或内网传输工具带到目标机器。如果你从源码包自己编译那还要注意 automake、autoconf 这些工具是否齐全。我一般优先选 rpm 方式因为依赖关系清晰卸载也干净源码编译作为备选方案适用于拿不到现成 rpm 的情况。3. 离线安装包准备在联网机器上把这些都备齐3.1 用 yumdownloader 抓取 rpm 包你现在需要在另一台能连外网的 CentOS 机器上把目标环境会用到的 rpm 包一次性下载全。最常用的是yumdownloader工具它在yum-utils包里。确保先安装好这个工具yum install -y yum-utils然后执行下载注意一定要带--resolve它会把依赖包也一起拉下来mkdir -p /root/stress-rpms cd /root/stress-rpms yumdownloader --resolve --destdir/root/stress-rpms stress这里--destdir指定输出目录--resolve是核心参数表示把 stress 依赖的所有 rpm 包全部下载下来。下载完成后你会看到stress-1.0.4-*.rpm以及若干个依赖包比如glibc、libgcc之类。千万不要只拷stress那一个文件我见过有人只带了主包就进内网结果安装时提示依赖缺失又得出来重新拉。3.2 补齐编译工具链的离线包如果你目标机器上连 gcc、make 都没有就需要在联网机器上再抓一套工具链。最省事的做法是直接指定一组包名yumdownloader --resolve --destdir/root/toolchain-rpms \ gcc make glibc-devel libstdc-develgcc是 C 编译器make是构建工具glibc-devel提供头文件和静态库编译 C 程序时必须要有。这里有一点要注意gcc 的依赖比较多--resolve拉下来的包可能有几十个打包时要保留完整的目录结构不要只挑看起来顺眼的几个文件。我曾经漏掉了cpp包结果 gcc 装上了却没法编译报错/usr/libexec/gcc/.../cc1: No such file or directory就是因为cpp没装上。3.3 准备源码包备用除了 rpm我还习惯在 U 盘里放一份 stress 的源码包比如stress-1.0.5.tar.gz。为什么多此一举因为 rpm 包已经能解决大部分需求但万一目标机器的 CentOS 版本很旧比如 6.xrpm 包的依赖要求可能满足不了源码编译反而更灵活。下载源码包时直接找官方发布页的 tarball下载后先本地校验一下大小和 MD5避免传输过程中损坏。源码包不需要安装只需要确保它能被解压到目标机器上即可。4. 内网安装与配置两种方式任选4.1 方式一rpm 离线安装推荐把之前下载的/root/stress-rpms目录整个拷贝到目标机器上进入该目录后执行cd /root/stress-rpms rpm -ivh *.rpm-ivh三个参数分别表示安装、显示详细信息、显示进度条。因为包名带通配符rpm 会自动处理当前目录下所有 rpm 文件。如果遇到依赖顺序问题可以改成rpm -Uvh *.rpm --nodeps强行忽略依赖千万不要一开始就用--nodeps那会掩盖真实的依赖缺失。正确做法是先直接执行如果提示缺libc.so.6就用rpm -qpR stress*.rpm查看具体依赖再确认对应 rpm 包是否已在目录里。我在 CentOS 7 上这样安装时所有依赖都齐了一次性成功。4.2 方式二源码编译安装如果你拿不到 rpm只好走源码编译。先把 tar 包解压再按标准三步走tar -zxvf stress-1.0.5.tar.gz cd stress-1.0.5 ./configure make make install./configure会检测系统里的编译器、头文件、库文件生成 Makefilemake根据 Makefile 编译出可执行文件make install默认把二进制安装到/usr/local/bin所以之后直接执行stress就能调用。编译时如果报configure: error: cannot find a C compiler说明 gcc 没装好回到第 3.2 节补包。如果报math.h: No such file or directory则说明缺glibc-devel。源码包的优势是可以自定义安装路径比如装到/opt/stress/bin/stress这样以后要清理应用删一个目录就行不会污染系统目录。4.3 配置 PATH 与检查环境无论哪种方式装完都需要确认可执行文件所在的目录是否在 PATH 里。rpm 方式默认装在/usr/bin源码编译默认在/usr/local/bin这两个路径通常都在 PATH 中。但如果你用了自定义前缀就需要手动配置export PATH$PATH:/opt/stress/bin echo export PATH$PATH:/opt/stress/bin /etc/profile source /etc/profile这里第一句是临时生效第二句写入系统全局变量第三句让当前会话立即生效。注意source /etc/profile只对当前终端有效新开的终端会自动加载。配置完 PATH 后执行which stress和stress --version来确认命令可以被找到且版本正确。我之前有一次把stress装到了/usr/local/bin但机器自定义过 PATH导致which找不到还以为是安装失败其实是路径没有导出。5. 常见问题与排查离线安装 stress 的五个典型坑5.1 rpm 安装时提示依赖缺失现象执行rpm -ivh *.rpm时系统报错error: Failed dependencies: libc.so.6(GLIBC_2.15)(64bit) is needed by stress-...。原因rpm 包在联网机器上下载时--resolve只解决了那台机器的依赖关系。如果目标机器 glibc 版本过低或依赖包没有完全拷贝过去就会导致安装时缺符号。解决先运行rpm -qpR stress*.rpm列出这个包需要的所有动态库和依赖再对照/root/stress-rpms目录里已有的文件。如果确实缺某个 rpm回到联网机器重新用yumdownloader --resolve补拉一次。千万不要盲目--nodeps否则装完根本跑不起来压测时才发现问题更麻烦。5.2 源码编译时找不到 math 库现象执行./configure时出现checking for library containing pow... no或者make时直接报undefined reference topow。原因stress 源码用到了数学库libm但 configure 脚本没有正确找到它或者系统缺少glibc-devel头文件。解决确认glibc-devel已通过 rpm 方式安装然后运行命令./configure LDFLAGS-lm-lm参数告诉链接器显式链接数学库。如果还不行就打开生成的config.log搜索error:关键字看是缺头文件还是缺库。这条排查路径对大部分 configure 失败都适用。5.3 安装成功但提示 command not found现象rpm -ivh或者make install都显示成功但新开终端执行stress报command not found。原因安装路径没有包含在 PATH 环境变量里。rpm 默认装到/usr/bin一般不会出问题但源码编译且指定了--prefix时很容易踩这个坑。还有可能是原本的 PATH 被/etc/profile中一段错误配置覆盖了。解决执行find / -name stress -type f 2/dev/null找到实际安装位置然后按 4.3 节的方式设置 PATH。这里特别提醒不要直接改 root 的.bashrc一旦写错会导致所有命令都找不到最好先验证export PATH$PATH:/新路径能生效再写入全局配置文件。5.4 压测时 CPU 消耗与预期不符现象执行stress --cpu 8后用top观察发现只有 2 个 CPU 满载其余核心闲置。原因stress 默认调用fork()创建指定数量的进程但如果系统配置了 cgroup 或 CPU 绑定进程只能跑在允许的核上。另外如果虚拟机上给的操作系统只看到了 2 个 vCPU那么--cpu 8只会让这 2 个核跑满。解决压测前先用lscpu查看实际可用的 CPU 数量和配额。如果确认系统只有 4 核那么--cpu 4就能打满。如果仍有闲置检查是否设置了taskset或 cgroup 限制cat /proc/self/status | grep Cpus_allowed_list这个输出会告诉你当前进程允许运行在哪个 CPU 列表上。如果显示0-1即使你请求 8 个进程也只能用 2 个核。5.5 内网源里拿到的 stress 版本太旧现象从内网自建 yum 源里找到了stress但版本是 1.0.3 或更老压测内存时一直报参数错误。原因老版本对内存单位支持不完整比如--vm-bytes只接受字节数不支持GB这样的大单位写法导致配置脚本执行失败。解决尽量用 1.0.5 的 rpm 或源码包替换老版本。如果无法替换就在命令参数里把单位换算成字节比如 4GB 写成4294967296。但我不建议这么做因为更早版本的 stress 在某些 64 位内核上有内存统计不准确的问题会直接影响压测结果的可信度。6. 验证跑通用 stress 做一次真正的压力测试装完 stress 只是第一步真正关键的是确认它能产生负载并且你能观测到负载。我的习惯是先做一次短时间压测同时开两个终端一个跑命令一个观察系统状态。先执行一次 30 秒的 CPU 和内存联合压测stress --cpu 4 --vm 2 --vm-bytes 1G --timeout 30这个命令的意思是创建 4 个 CPU 繁忙进程再创建 2 个虚拟内存分配进程每个进程分配 1GB 内存整体运行 30 秒。--vm-bytes 1G是 stress 1.0.5 支持的写法如果你用的是 1.0.4也可以写成--vm-bytes 1073741824。执行后打开另一个终端运行top或uptimetop -b -n 1 | head -20你应当看到%CPU中有多个进程接近 100%并且在KiB Mem行看到内存被占用了约 2GB。如果top里没变化先检查你自己是否把stress命令放在了后台执行却没有带那样压测进程会占用当前终端根本没法再开第二个终端观察。更典型的错误是忘记设置--timeout导致压测无限期进行最后系统负载过高连登录都卡只能重启。压测结束后系统负载并不会瞬间回落因为进程退出需要时间。此时再执行uptime观察 1 分钟、5 分钟、15 分钟的平均负载值你会发现 1 分钟负载在逐步下降而 5 分钟和 15 分钟仍然维持高位。这是正常现象不要误以为 stress 没退出。为了确认进程已经清干净可以执行pgrep -l stress如果没有任何输出说明压测进程全部退出。如果还有残留执行pkill -9 stress强制清理。我从那以后每次跑完压测都会强制走一遍这个检查流程无论屏幕上显示超时退出还是手动中断都要确认进程列表里没有残留否则下次做基准测试时数据会被上一次的残留进程污染。希望这点经验能帮你少走一些弯路。本文还有配套的精品资源点击获取