尧图网站建设 
简介本资源面向需要在无外网环境下开展Linux性能压测的运维与测试人员提供CentOS平台stress工具的离线安装方案。包内整合了stress-1.0.4源码包及配套依赖并附带sar命令相关组件可解决生产服务器无法联网、无法通过yum在线安装压测工具的痛点适合具备一定Linux基础、需要做CPU、内存、IO压力验证的中高级使用者。资源共43个文件以11个rpm依赖包为主同时包含configure、install-sh等构建脚本以及readme、changelog、news等说明文档和c源码文件压缩包整体约46.66MB目录结构完整便于按需取用。目前已有2585人学习下载。借助该资源读者可快速完成stress的编译与离线部署结合sar命令采集系统负载数据掌握压测过程中的资源监控与结果分析方法为服务器稳定性验证和性能调优提供可复用的工具链与排错参考。1. CentOS 离线装 stress内网机器压测绕不开的一道坎机房里有台 CentOS 7.9 的业务机网卡只通了内网yum 源指向的地址早就不可达可偏偏要在这台机器上做 CPU、内存、IO 的稳定性压测。这时候yum install stress会直接卡在 resolving 阶段报一堆Could not resolve host或者Cannot find a valid baseurl。stress 这个工具本身很小源码也就几百 KB但它的依赖链在离线环境里会咬人——gcc、make、libgcc、glibc-devel缺一个都编不过。所以「linux centos stress 离线安装」这件事本质不是装一个包而是要在断网机器上补齐一条最小可用的编译或安装链路。这篇写给两类人一类是运维手里只有一台内网 CentOS需要快速把压测跑起来另一类是刚接手国产化替代或内网交付的工程师第一次遇到没有外网还要装工具的场景。下面按「先判断能不能直接装 rpm → 不行就源码编译 → 再不行就交叉编译搬过去」这条线走把参数和坑都摊开。2. 先判断路线rpm 直装、源码编译还是外部编译搬运2.1 三条路线的适用边界在动手之前先花两分钟确认这台 CentOS 到底适合哪条路。判断依据不是「哪个快」而是「目标机器上有没有编译环境」和「能不能拿到匹配的 rpm 包」。路线前提条件耗时风险点rpm 直装能找到与目标系统 glibc 版本匹配的 stress rpm1 分钟依赖缺失--nodeps强装后运行报错源码编译目标机有 gcc、make、glibc-devel5 分钟缺开发包编译中断外部编译搬运目标机无编译环境但有一台同版本联网机15 分钟动态库版本不一致搬过去跑不起来我一般会先跑一条命令看目标机有没有编译能力# 检查编译工具链是否齐全 which gcc make gcc --version make --version # 检查 glibc 开发包是否存在编译 stress 必需 rpm -q glibc-devel glibc-headers如果gcc和make都有glibc-devel也在那直接走源码编译最干净。如果只有gcc没有make或者glibc-devel缺失就得考虑从同版本的联网机器上把 rpm 包下下来用rpm -ivh逐个补。如果目标机连gcc都没有那就走第三条路在一台同版本 CentOS 上编译好把二进制和它依赖的.so一起打包搬过去。提示glibc-devel的版本必须和系统glibc主版本一致CentOS 7.9 对应的是glibc-2.17拿 CentOS 8 的包过来装会直接冲突。2.2 确认系统版本和架构避免下错包离线安装翻车最常见的原因就是包下错了。CentOS 7.9 的uname -r是3.10.0-1160架构大概率是x86_64但也有aarch64的国产化机器。先确认# 查看系统版本、内核、架构三件套 cat /etc/centos-release uname -r uname -m # 查看 glibc 版本决定 rpm 包能不能用 ldd --version | head -1/etc/centos-release输出CentOS Linux release 7.9.2009 (Core)uname -m输出x86_64ldd --version第一行是ldd (GNU libc) 2.17。这三个信息记下来后面找包、编译、搬运都靠它们对齐。如果是aarch64源码编译时./configure一般不用改但 rpm 包必须找aarch64版本x86_64 的包装不上。2.3 源码编译 stress 的最小依赖清单stress 的源码依赖非常少核心就三个gcc、make、glibc-devel。它不依赖autoconf生成的复杂脚本源码包里自带configure。如果目标机缺glibc-devel编译时会报fatal error: stdio.h: No such file or directory这个报错就是头文件缺失的典型信号。在联网机器上可以用yumdownloader把这三个包及其依赖一次性下全# 在联网的同版本 CentOS 上执行下载编译依赖到本地目录 mkdir -p /tmp/stress-offline cd /tmp/stress-offline yumdownloader --resolve --destdir/tmp/stress-offline \ gcc make glibc-devel glibc-headers kernel-headers # 查看下载了哪些包 ls -lh /tmp/stress-offline/--resolve会把依赖树一起拉下来--destdir指定存放目录。下载完通常有十几个 rpm包括mpfr、cpp、libmpc这些间接依赖。把这些 rpm 拷到目标机用rpm -ivh *.rpm一次性装。注意安装顺序rpm会自动处理依赖但如果报Failed dependencies就按报错提示的包名单独先装。3. 源码编译 stress从 configure 到 make install 的完整命令3.1 获取 stress 源码并校验完整性stress 的源码包很小常见做法是从官方发布页拿stress-1.0.4.tar.gz。离线环境下先在联网机下载再用 U 盘或内网共享拷进去。下载后务必校验避免传输损坏导致解压报错# 在联网机下载源码包 wget https://fossies.org/linux/privat/stress-1.0.4.tar.gz # 计算 sha256 并记录拷到目标机后比对 sha256sum stress-1.0.4.tar.gz # 目标机上再次校验两个值必须一致 sha256sum stress-1.0.4.tar.gz如果目标机没有wget就在联网机下好再拷。校验这一步别省我遇到过 U 盘拷贝导致 gzip 解压到一半报unexpected end of file的情况重新拷一遍就好了。源码包解压tar -zxvf stress-1.0.4.tar.gz cd stress-1.0.4 ls -l正常会看到configure、Makefile.in、src/目录。如果configure没有可执行权限chmod x configure补一下。3.2 configure 阶段的关键参数stress 的configure脚本很简单但离线环境下有两个参数值得注意# 指定安装前缀避免装到 /usr/local 后 PATH 找不到 ./configure --prefix/usr/local/stress # 如果目标机 CPU 架构特殊可显式指定 host ./configure --prefix/usr/local/stress --hostx86_64-linux-gnu--prefix决定make install后二进制放哪。默认是/usr/localstress可执行文件会落在/usr/local/bin。如果/usr/local/bin不在PATH里装完直接敲stress会提示command not found这时候要么把/usr/local/bin加进PATH要么用绝对路径/usr/local/bin/stress调用。--host一般不用写configure会自动探测只有在交叉编译或架构识别异常时才显式指定。configure跑完会输出一段摘要重点看checking for gcc... gcc和checking for stdio.h... yes。如果stdio.h那行是no说明glibc-devel没装好回到 2.3 补装。3.3 make 与 make install 的实操与验证configure通过后编译和安装就两条命令# 编译-j 后面跟 CPU 核数加快速度 make -j$(nproc) # 安装到 configure 指定的 prefix make install # 验证安装结果 /usr/local/stress/bin/stress --versionmake -j$(nproc)里的$(nproc)会自动取当前 CPU 核数比如 8 核就等价于make -j8。stress 源码量小单核编译也就十几秒-j主要是习惯。make install会把stress二进制拷到/usr/local/stress/bin/同时可能装一个 man page。验证时用绝对路径确认输出版本号stress 1.0.4就成功了。如果make报cc1: error: unrecognized command line option -stdgnu11说明gcc版本太老CentOS 7.9 自带的gcc 4.8.5支持gnu11一般不会出这个问题。真遇到就检查是不是gcc被替换成了别的编译器。3.4 把 stress 加进 PATH 并做一次冒烟压测装完后为了方便把二进制目录加进PATH# 临时生效 export PATH$PATH:/usr/local/stress/bin # 永久生效写入 profile echo export PATH$PATH:/usr/local/stress/bin /etc/profile source /etc/profile # 冒烟测试2 个 CPU worker 压 10 秒 stress --cpu 2 --timeout 10s--cpu 2表示起 2 个进程反复计算平方根--timeout 10s表示 10 秒后自动退出。跑起来后另开一个终端用top看应该有两个stress进程各占接近 100% 的 CPU。10 秒后自动结束没有报错就说明安装完全可用。这一步别跳过它能同时验证二进制可执行、动态库可加载、参数解析正常。4. 无编译环境时的搬运方案静态链接与依赖打包4.1 用静态链接编一个不依赖 glibc 的 stress如果目标机连glibc-devel都装不上最稳的办法是在联网机上编一个静态链接版本。stress 本身不涉及复杂的系统调用静态链接完全可行# 在联网的同版本 CentOS 上操作 tar -zxvf stress-1.0.4.tar.gz cd stress-1.0.4 # 关闭动态链接强制静态编译 ./configure --prefix/tmp/stress-static LDFLAGS-static make -j$(nproc) make install # 检查是否真的静态链接 file /tmp/stress-static/bin/stress ldd /tmp/stress-static/bin/stressLDFLAGS-static是关键它让链接器把所有依赖库都打进二进制。file命令输出里如果带statically linked就说明成功了。ldd对静态二进制会输出not a dynamic executable这也是正常现象。静态版 stress 体积会从几十 KB 涨到 1 MB 左右但拷到任何同架构的 CentOS 上都能直接跑不用管 glibc 版本。4.2 动态链接版的依赖打包与 LD_LIBRARY_PATH如果静态编译因为某些库没有静态版本而失败就退回动态链接搬运。思路是把stress二进制和它依赖的.so一起打包# 在编译机上查看 stress 依赖哪些动态库 ldd /usr/local/stress/bin/stress # 输出示例 # linux-vdso.so.1 # libc.so.6 /lib64/libc.so.6 # /lib64/ld-linux-x86-64.so.2 # 把二进制和依赖库按原路径结构打包 mkdir -p /tmp/stress-bundle/lib64 cp /usr/local/stress/bin/stress /tmp/stress-bundle/ cp /lib64/libc.so.6 /tmp/stress-bundle/lib64/ cp /lib64/ld-linux-x86-64.so.2 /tmp/stress-bundle/lib64/ tar -czvf stress-bundle.tar.gz -C /tmp/stress-bundle .搬到目标机后解压用LD_LIBRARY_PATH指定库路径运行tar -zxvf stress-bundle.tar.gz -C /opt/stress-bundle export LD_LIBRARY_PATH/opt/stress-bundle/lib64:$LD_LIBRARY_PATH /opt/stress-bundle/stress --versionLD_LIBRARY_PATH让动态链接器优先从指定目录找库。这种方式的坑在于libc.so.6和ld-linux必须与目标机内核兼容CentOS 7.9 之间搬运没问题跨大版本比如从 CentOS 8 搬到 7大概率报GLIBC_2.28 not found。所以搬运方案的前提是编译机和目标机同版本。4.3 验证搬运版本能否正常压测搬运过去后别只看--version要实际跑一次压测确认没有运行时错误# 内存压测2 个 worker 各分配 256MB持续 30 秒 /opt/stress-bundle/stress --vm 2 --vm-bytes 256M --timeout 30s # 另开终端观察内存和进程状态 watch -n 2 ps aux | grep stress | grep -v grep--vm 2起 2 个内存压测进程--vm-bytes 256M每个进程反复分配和释放 256MB 内存。如果动态库有问题这一步会直接报error while loading shared libraries或者段错误。跑满 30 秒无异常才算搬运成功。watch那条命令每 2 秒刷新一次能看到stress进程的 RSS 内存在 256MB 附近波动。5. 避坑与排查离线装 stress 最容易翻车的 5 个点5.1 现象configure 报 cannot find install-sh原因源码包解压时权限丢失或者configure脚本没有可执行权限导致它调用的辅助脚本找不到。解决进源码目录执行chmod -R x .或者直接sh configure绕过执行权限。更彻底的办法是重新解压用tar -zxvf而不是tar -xvf确保权限位保留。5.2 现象make 报 fatal error: stdio.h: No such file or directory原因glibc-devel或glibc-headers没装编译器找不到标准头文件。解决从同版本 CentOS 的镜像里找glibc-devel-2.17-*.rpm和glibc-headers-2.17-*.rpm用rpm -ivh装上。装之前用rpm -q glibc-devel确认当前状态如果显示not installed就是它的问题。注意kernel-headers有时也要一起装否则某些系统调用头文件缺失。5.3 现象rpm -ivh 报 Failed dependencies: libmpc.so.3原因gcc的依赖链没下全yumdownloader --resolve有时会漏掉间接依赖。解决在联网机上用yum deplist gcc列出完整依赖逐个yumdownloader下载。或者更省事直接在有网的机器上yum install gcc make glibc-devel然后把/var/cache/yum里的 rpm 全拷走。安装时如果还报依赖用rpm -ivh --nodeps强装但强装后必须实际编译一次验证不能只看安装成功。5.4 现象stress 跑起来后立刻退出无任何输出原因--timeout参数格式写错比如写成--timeout 10而不是--timeout 10sstress 会把它当成 0 秒直接退出。解决时间单位必须带s、m、h例如--timeout 30s、--timeout 5m。另外--cpu和--vm不能同时为 0至少指定一个压测类型否则 stress 也会立即退出。5.5 现象搬运的二进制在目标机报 GLIBC_2.28 not found原因编译机和目标机的 glibc 版本不一致编译机版本更高。解决回到与目标机同版本的机器上重新编译或者改用静态链接方案。判断方法是在目标机执行ldd --version和编译机对比主版本号。CentOS 7.9 是 2.17CentOS 8 是 2.28跨版本搬运动态链接二进制基本不可行。静态链接版不受此限制但要注意静态链接的glibc在某些系统调用上行为略有差异压测 CPU 和内存没问题压测涉及网络的部分要额外验证。6. 把 stress 用出价值压测参数组合与结果判读装好只是开始真正要的是用 stress 压出有意义的数据。我一般会按「单维度基线 → 混合负载 → 长稳」三步走。单维度基线先单独压 CPU、内存、IO记录系统在单一压力下的表现# CPU 基线4 核满载 60 秒同时用 vmstat 采样 stress --cpu 4 --timeout 60s vmstat 5 12 /tmp/cpu-baseline.txt # 内存基线4 个 worker 各 512MB持续 60 秒 stress --vm 4 --vm-bytes 512M --timeout 60s vmstat 5 12 /tmp/vm-baseline.txt # IO 基线4 个 worker 反复 sync持续 60 秒 stress --io 4 --timeout 60s iostat -x 5 12 /tmp/io-baseline.txtvmstat 5 12表示每 5 秒采样一次共 12 次覆盖 60 秒压测窗口。重点看r列运行队列长度和si/soswap 换入换出。CPU 压测时r应该接近核数si/so为 0内存压测时如果si/so持续非零说明物理内存不够开始用 swap 了这时候压测结果就不能代表纯内存性能。iostat -x看%util和awaitIO 压测时%util接近 100% 是正常的但await如果超过 50ms说明磁盘已经是瓶颈。混合负载用一条命令同时压 CPU、内存、IO# 混合压测2 CPU 2 内存 2 IO持续 300 秒 stress --cpu 2 --vm 2 --vm-bytes 256M --io 2 --timeout 300s混合压测的价值在于观察资源争抢。比如 CPU 和 IO 同时压的时候vmstat的waIO 等待列会升高如果wa超过 30%说明 IO 拖累了整体性能。长稳测试把--timeout拉到1h甚至更长配合sar做趋势记录# 长稳后台跑 1 小时sar 每 60 秒记录一次 nohup stress --cpu 4 --vm 2 --vm-bytes 512M --timeout 1h /tmp/stress-long.log 21 sar -u -r -d 60 60 /tmp/sar-long.txtsar -u -r -d 60 60表示每 60 秒采样一次共 60 次覆盖 1 小时。-u是 CPU-r是内存-d是磁盘。长稳结束后看/tmp/sar-long.txt重点找有没有随时间推移而恶化的指标比如内存%memused持续上涨不回落那可能是压测进程有内存泄漏也可能是系统缓存策略问题。我自己的习惯是每次压测前先sync echo 3 /proc/sys/vm/drop_caches清一次缓存让基线一致否则第二次压测的结果会被上一次的缓存干扰。这个习惯帮我省过好几次「怎么这次数据对不上」的后悔药。希望帮到你。本文还有配套的精品资源点击获取 CentOS 7.9 离线安装 stress 压测工具：源码编译与依赖打包实战
简介本资源面向需要在无外网环境下开展Linux性能压测的运维与测试人员提供CentOS平台stress工具的离线安装方案。包内整合了stress-1.0.4源码包及配套依赖并附带sar命令相关组件可解决生产服务器无法联网、无法通过yum在线安装压测工具的痛点适合具备一定Linux基础、需要做CPU、内存、IO压力验证的中高级使用者。资源共43个文件以11个rpm依赖包为主同时包含configure、install-sh等构建脚本以及readme、changelog、news等说明文档和c源码文件压缩包整体约46.66MB目录结构完整便于按需取用。目前已有2585人学习下载。借助该资源读者可快速完成stress的编译与离线部署结合sar命令采集系统负载数据掌握压测过程中的资源监控与结果分析方法为服务器稳定性验证和性能调优提供可复用的工具链与排错参考。1. CentOS 离线装 stress内网机器压测绕不开的一道坎机房里有台 CentOS 7.9 的业务机网卡只通了内网yum 源指向的地址早就不可达可偏偏要在这台机器上做 CPU、内存、IO 的稳定性压测。这时候yum install stress会直接卡在 resolving 阶段报一堆Could not resolve host或者Cannot find a valid baseurl。stress 这个工具本身很小源码也就几百 KB但它的依赖链在离线环境里会咬人——gcc、make、libgcc、glibc-devel缺一个都编不过。所以「linux centos stress 离线安装」这件事本质不是装一个包而是要在断网机器上补齐一条最小可用的编译或安装链路。这篇写给两类人一类是运维手里只有一台内网 CentOS需要快速把压测跑起来另一类是刚接手国产化替代或内网交付的工程师第一次遇到没有外网还要装工具的场景。下面按「先判断能不能直接装 rpm → 不行就源码编译 → 再不行就交叉编译搬过去」这条线走把参数和坑都摊开。2. 先判断路线rpm 直装、源码编译还是外部编译搬运2.1 三条路线的适用边界在动手之前先花两分钟确认这台 CentOS 到底适合哪条路。判断依据不是「哪个快」而是「目标机器上有没有编译环境」和「能不能拿到匹配的 rpm 包」。路线前提条件耗时风险点rpm 直装能找到与目标系统 glibc 版本匹配的 stress rpm1 分钟依赖缺失--nodeps强装后运行报错源码编译目标机有 gcc、make、glibc-devel5 分钟缺开发包编译中断外部编译搬运目标机无编译环境但有一台同版本联网机15 分钟动态库版本不一致搬过去跑不起来我一般会先跑一条命令看目标机有没有编译能力# 检查编译工具链是否齐全 which gcc make gcc --version make --version # 检查 glibc 开发包是否存在编译 stress 必需 rpm -q glibc-devel glibc-headers如果gcc和make都有glibc-devel也在那直接走源码编译最干净。如果只有gcc没有make或者glibc-devel缺失就得考虑从同版本的联网机器上把 rpm 包下下来用rpm -ivh逐个补。如果目标机连gcc都没有那就走第三条路在一台同版本 CentOS 上编译好把二进制和它依赖的.so一起打包搬过去。提示glibc-devel的版本必须和系统glibc主版本一致CentOS 7.9 对应的是glibc-2.17拿 CentOS 8 的包过来装会直接冲突。2.2 确认系统版本和架构避免下错包离线安装翻车最常见的原因就是包下错了。CentOS 7.9 的uname -r是3.10.0-1160架构大概率是x86_64但也有aarch64的国产化机器。先确认# 查看系统版本、内核、架构三件套 cat /etc/centos-release uname -r uname -m # 查看 glibc 版本决定 rpm 包能不能用 ldd --version | head -1/etc/centos-release输出CentOS Linux release 7.9.2009 (Core)uname -m输出x86_64ldd --version第一行是ldd (GNU libc) 2.17。这三个信息记下来后面找包、编译、搬运都靠它们对齐。如果是aarch64源码编译时./configure一般不用改但 rpm 包必须找aarch64版本x86_64 的包装不上。2.3 源码编译 stress 的最小依赖清单stress 的源码依赖非常少核心就三个gcc、make、glibc-devel。它不依赖autoconf生成的复杂脚本源码包里自带configure。如果目标机缺glibc-devel编译时会报fatal error: stdio.h: No such file or directory这个报错就是头文件缺失的典型信号。在联网机器上可以用yumdownloader把这三个包及其依赖一次性下全# 在联网的同版本 CentOS 上执行下载编译依赖到本地目录 mkdir -p /tmp/stress-offline cd /tmp/stress-offline yumdownloader --resolve --destdir/tmp/stress-offline \ gcc make glibc-devel glibc-headers kernel-headers # 查看下载了哪些包 ls -lh /tmp/stress-offline/--resolve会把依赖树一起拉下来--destdir指定存放目录。下载完通常有十几个 rpm包括mpfr、cpp、libmpc这些间接依赖。把这些 rpm 拷到目标机用rpm -ivh *.rpm一次性装。注意安装顺序rpm会自动处理依赖但如果报Failed dependencies就按报错提示的包名单独先装。3. 源码编译 stress从 configure 到 make install 的完整命令3.1 获取 stress 源码并校验完整性stress 的源码包很小常见做法是从官方发布页拿stress-1.0.4.tar.gz。离线环境下先在联网机下载再用 U 盘或内网共享拷进去。下载后务必校验避免传输损坏导致解压报错# 在联网机下载源码包 wget https://fossies.org/linux/privat/stress-1.0.4.tar.gz # 计算 sha256 并记录拷到目标机后比对 sha256sum stress-1.0.4.tar.gz # 目标机上再次校验两个值必须一致 sha256sum stress-1.0.4.tar.gz如果目标机没有wget就在联网机下好再拷。校验这一步别省我遇到过 U 盘拷贝导致 gzip 解压到一半报unexpected end of file的情况重新拷一遍就好了。源码包解压tar -zxvf stress-1.0.4.tar.gz cd stress-1.0.4 ls -l正常会看到configure、Makefile.in、src/目录。如果configure没有可执行权限chmod x configure补一下。3.2 configure 阶段的关键参数stress 的configure脚本很简单但离线环境下有两个参数值得注意# 指定安装前缀避免装到 /usr/local 后 PATH 找不到 ./configure --prefix/usr/local/stress # 如果目标机 CPU 架构特殊可显式指定 host ./configure --prefix/usr/local/stress --hostx86_64-linux-gnu--prefix决定make install后二进制放哪。默认是/usr/localstress可执行文件会落在/usr/local/bin。如果/usr/local/bin不在PATH里装完直接敲stress会提示command not found这时候要么把/usr/local/bin加进PATH要么用绝对路径/usr/local/bin/stress调用。--host一般不用写configure会自动探测只有在交叉编译或架构识别异常时才显式指定。configure跑完会输出一段摘要重点看checking for gcc... gcc和checking for stdio.h... yes。如果stdio.h那行是no说明glibc-devel没装好回到 2.3 补装。3.3 make 与 make install 的实操与验证configure通过后编译和安装就两条命令# 编译-j 后面跟 CPU 核数加快速度 make -j$(nproc) # 安装到 configure 指定的 prefix make install # 验证安装结果 /usr/local/stress/bin/stress --versionmake -j$(nproc)里的$(nproc)会自动取当前 CPU 核数比如 8 核就等价于make -j8。stress 源码量小单核编译也就十几秒-j主要是习惯。make install会把stress二进制拷到/usr/local/stress/bin/同时可能装一个 man page。验证时用绝对路径确认输出版本号stress 1.0.4就成功了。如果make报cc1: error: unrecognized command line option -stdgnu11说明gcc版本太老CentOS 7.9 自带的gcc 4.8.5支持gnu11一般不会出这个问题。真遇到就检查是不是gcc被替换成了别的编译器。3.4 把 stress 加进 PATH 并做一次冒烟压测装完后为了方便把二进制目录加进PATH# 临时生效 export PATH$PATH:/usr/local/stress/bin # 永久生效写入 profile echo export PATH$PATH:/usr/local/stress/bin /etc/profile source /etc/profile # 冒烟测试2 个 CPU worker 压 10 秒 stress --cpu 2 --timeout 10s--cpu 2表示起 2 个进程反复计算平方根--timeout 10s表示 10 秒后自动退出。跑起来后另开一个终端用top看应该有两个stress进程各占接近 100% 的 CPU。10 秒后自动结束没有报错就说明安装完全可用。这一步别跳过它能同时验证二进制可执行、动态库可加载、参数解析正常。4. 无编译环境时的搬运方案静态链接与依赖打包4.1 用静态链接编一个不依赖 glibc 的 stress如果目标机连glibc-devel都装不上最稳的办法是在联网机上编一个静态链接版本。stress 本身不涉及复杂的系统调用静态链接完全可行# 在联网的同版本 CentOS 上操作 tar -zxvf stress-1.0.4.tar.gz cd stress-1.0.4 # 关闭动态链接强制静态编译 ./configure --prefix/tmp/stress-static LDFLAGS-static make -j$(nproc) make install # 检查是否真的静态链接 file /tmp/stress-static/bin/stress ldd /tmp/stress-static/bin/stressLDFLAGS-static是关键它让链接器把所有依赖库都打进二进制。file命令输出里如果带statically linked就说明成功了。ldd对静态二进制会输出not a dynamic executable这也是正常现象。静态版 stress 体积会从几十 KB 涨到 1 MB 左右但拷到任何同架构的 CentOS 上都能直接跑不用管 glibc 版本。4.2 动态链接版的依赖打包与 LD_LIBRARY_PATH如果静态编译因为某些库没有静态版本而失败就退回动态链接搬运。思路是把stress二进制和它依赖的.so一起打包# 在编译机上查看 stress 依赖哪些动态库 ldd /usr/local/stress/bin/stress # 输出示例 # linux-vdso.so.1 # libc.so.6 /lib64/libc.so.6 # /lib64/ld-linux-x86-64.so.2 # 把二进制和依赖库按原路径结构打包 mkdir -p /tmp/stress-bundle/lib64 cp /usr/local/stress/bin/stress /tmp/stress-bundle/ cp /lib64/libc.so.6 /tmp/stress-bundle/lib64/ cp /lib64/ld-linux-x86-64.so.2 /tmp/stress-bundle/lib64/ tar -czvf stress-bundle.tar.gz -C /tmp/stress-bundle .搬到目标机后解压用LD_LIBRARY_PATH指定库路径运行tar -zxvf stress-bundle.tar.gz -C /opt/stress-bundle export LD_LIBRARY_PATH/opt/stress-bundle/lib64:$LD_LIBRARY_PATH /opt/stress-bundle/stress --versionLD_LIBRARY_PATH让动态链接器优先从指定目录找库。这种方式的坑在于libc.so.6和ld-linux必须与目标机内核兼容CentOS 7.9 之间搬运没问题跨大版本比如从 CentOS 8 搬到 7大概率报GLIBC_2.28 not found。所以搬运方案的前提是编译机和目标机同版本。4.3 验证搬运版本能否正常压测搬运过去后别只看--version要实际跑一次压测确认没有运行时错误# 内存压测2 个 worker 各分配 256MB持续 30 秒 /opt/stress-bundle/stress --vm 2 --vm-bytes 256M --timeout 30s # 另开终端观察内存和进程状态 watch -n 2 ps aux | grep stress | grep -v grep--vm 2起 2 个内存压测进程--vm-bytes 256M每个进程反复分配和释放 256MB 内存。如果动态库有问题这一步会直接报error while loading shared libraries或者段错误。跑满 30 秒无异常才算搬运成功。watch那条命令每 2 秒刷新一次能看到stress进程的 RSS 内存在 256MB 附近波动。5. 避坑与排查离线装 stress 最容易翻车的 5 个点5.1 现象configure 报 cannot find install-sh原因源码包解压时权限丢失或者configure脚本没有可执行权限导致它调用的辅助脚本找不到。解决进源码目录执行chmod -R x .或者直接sh configure绕过执行权限。更彻底的办法是重新解压用tar -zxvf而不是tar -xvf确保权限位保留。5.2 现象make 报 fatal error: stdio.h: No such file or directory原因glibc-devel或glibc-headers没装编译器找不到标准头文件。解决从同版本 CentOS 的镜像里找glibc-devel-2.17-*.rpm和glibc-headers-2.17-*.rpm用rpm -ivh装上。装之前用rpm -q glibc-devel确认当前状态如果显示not installed就是它的问题。注意kernel-headers有时也要一起装否则某些系统调用头文件缺失。5.3 现象rpm -ivh 报 Failed dependencies: libmpc.so.3原因gcc的依赖链没下全yumdownloader --resolve有时会漏掉间接依赖。解决在联网机上用yum deplist gcc列出完整依赖逐个yumdownloader下载。或者更省事直接在有网的机器上yum install gcc make glibc-devel然后把/var/cache/yum里的 rpm 全拷走。安装时如果还报依赖用rpm -ivh --nodeps强装但强装后必须实际编译一次验证不能只看安装成功。5.4 现象stress 跑起来后立刻退出无任何输出原因--timeout参数格式写错比如写成--timeout 10而不是--timeout 10sstress 会把它当成 0 秒直接退出。解决时间单位必须带s、m、h例如--timeout 30s、--timeout 5m。另外--cpu和--vm不能同时为 0至少指定一个压测类型否则 stress 也会立即退出。5.5 现象搬运的二进制在目标机报 GLIBC_2.28 not found原因编译机和目标机的 glibc 版本不一致编译机版本更高。解决回到与目标机同版本的机器上重新编译或者改用静态链接方案。判断方法是在目标机执行ldd --version和编译机对比主版本号。CentOS 7.9 是 2.17CentOS 8 是 2.28跨版本搬运动态链接二进制基本不可行。静态链接版不受此限制但要注意静态链接的glibc在某些系统调用上行为略有差异压测 CPU 和内存没问题压测涉及网络的部分要额外验证。6. 把 stress 用出价值压测参数组合与结果判读装好只是开始真正要的是用 stress 压出有意义的数据。我一般会按「单维度基线 → 混合负载 → 长稳」三步走。单维度基线先单独压 CPU、内存、IO记录系统在单一压力下的表现# CPU 基线4 核满载 60 秒同时用 vmstat 采样 stress --cpu 4 --timeout 60s vmstat 5 12 /tmp/cpu-baseline.txt # 内存基线4 个 worker 各 512MB持续 60 秒 stress --vm 4 --vm-bytes 512M --timeout 60s vmstat 5 12 /tmp/vm-baseline.txt # IO 基线4 个 worker 反复 sync持续 60 秒 stress --io 4 --timeout 60s iostat -x 5 12 /tmp/io-baseline.txtvmstat 5 12表示每 5 秒采样一次共 12 次覆盖 60 秒压测窗口。重点看r列运行队列长度和si/soswap 换入换出。CPU 压测时r应该接近核数si/so为 0内存压测时如果si/so持续非零说明物理内存不够开始用 swap 了这时候压测结果就不能代表纯内存性能。iostat -x看%util和awaitIO 压测时%util接近 100% 是正常的但await如果超过 50ms说明磁盘已经是瓶颈。混合负载用一条命令同时压 CPU、内存、IO# 混合压测2 CPU 2 内存 2 IO持续 300 秒 stress --cpu 2 --vm 2 --vm-bytes 256M --io 2 --timeout 300s混合压测的价值在于观察资源争抢。比如 CPU 和 IO 同时压的时候vmstat的waIO 等待列会升高如果wa超过 30%说明 IO 拖累了整体性能。长稳测试把--timeout拉到1h甚至更长配合sar做趋势记录# 长稳后台跑 1 小时sar 每 60 秒记录一次 nohup stress --cpu 4 --vm 2 --vm-bytes 512M --timeout 1h /tmp/stress-long.log 21 sar -u -r -d 60 60 /tmp/sar-long.txtsar -u -r -d 60 60表示每 60 秒采样一次共 60 次覆盖 1 小时。-u是 CPU-r是内存-d是磁盘。长稳结束后看/tmp/sar-long.txt重点找有没有随时间推移而恶化的指标比如内存%memused持续上涨不回落那可能是压测进程有内存泄漏也可能是系统缓存策略问题。我自己的习惯是每次压测前先sync echo 3 /proc/sys/vm/drop_caches清一次缓存让基线一致否则第二次压测的结果会被上一次的缓存干扰。这个习惯帮我省过好几次「怎么这次数据对不上」的后悔药。希望帮到你。本文还有配套的精品资源点击获取