简介：针对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.17，CentOS 8/9 会更高。这个参数决定了你能直接用别人编译好的二进制，还是必须自己源码编译。接下来再确认有没有安装基础编译工具：which gcc which make which rpmbuild如果which gcc和which make都没有输出，说明这台机器连编译环境都不完整。这时候你只有两条路：要么在联网的机器上把 gcc、make 的 rpm 包也一起抓下来带进去，要么找一个在同样 glibc 版本下编译好的 stress 静态二进制。我更推荐前者，因为静态二进制有时候会在运行时行为上有些微妙差异，而且后续如果还想装其他压测工具，编译环境早晚要用到。2.2 stress 版本怎么选stress 这个工具本身很轻量，官方最新版本一直停留在 1.0.5，1.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.x，rpm 包的依赖要求可能满足不了，源码编译反而更灵活。下载源码包时，直接找官方发布页的 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会检测系统里的编译器、头文件、库文件，生成 Makefile；make根据 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或uptime：top -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强制清理。我从那以后每次跑完压测都会强制走一遍这个检查流程，无论屏幕上显示超时退出还是手动中断，都要确认进程列表里没有残留，否则下次做基准测试时数据会被上一次的残留进程污染。希望这点经验能帮你少走一些弯路。本文还有配套的精品资源，点击获取
简介：针对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.17，CentOS 8/9 会更高。这个参数决定了你能直接用别人编译好的二进制，还是必须自己源码编译。接下来再确认有没有安装基础编译工具：which gcc which make which rpmbuild如果which gcc和which make都没有输出，说明这台机器连编译环境都不完整。这时候你只有两条路：要么在联网的机器上把 gcc、make 的 rpm 包也一起抓下来带进去，要么找一个在同样 glibc 版本下编译好的 stress 静态二进制。我更推荐前者，因为静态二进制有时候会在运行时行为上有些微妙差异，而且后续如果还想装其他压测工具，编译环境早晚要用到。2.2 stress 版本怎么选stress 这个工具本身很轻量，官方最新版本一直停留在 1.0.5，1.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.x，rpm 包的依赖要求可能满足不了，源码编译反而更灵活。下载源码包时，直接找官方发布页的 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会检测系统里的编译器、头文件、库文件，生成 Makefile；make根据 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或uptime：top -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强制清理。我从那以后每次跑完压测都会强制走一遍这个检查流程，无论屏幕上显示超时退出还是手动中断，都要确认进程列表里没有残留，否则下次做基准测试时数据会被上一次的残留进程污染。希望这点经验能帮你少走一些弯路。本文还有配套的精品资源，点击获取