简介面向需要在 CentOS 等 Linux 环境中开展性能压力测试的运维与开发人员这份离线安装资料围绕 stress-1.0.4 展开重点解决无外网或受限网络环境下压测工具及相关依赖部署不便的问题并兼顾 sar 性能观测命令的配套使用需求。压缩包共 43 个文件约 46.66MB主要由 rpm 依赖包、源码构建文件、说明文档与配置脚本组成既包含可直接离线安装的软件包也保留 stress 源码编译所需的构建文件内容组织上兼顾依赖补齐、安装验证与压测实践便于根据服务器环境选择安装方式。已有 2598 人学习下载。读者可据此搭建 CPU、内存、I/O 等基础压测环境配合 sar 采集系统负载数据进一步理解 stress 参数配置、依赖补齐、源码编译与常见排错思路适合作为 Linux 性能测试入门、离线部署与压测实验的参考材料。1. 内网机器睡不着觉的那晚stress 离线装机到底解决什么问题机房在四楼网线只通到内网交换机yum install一敲就是 timeout。这种环境做 linux 压力测试第一步不是写压测命令而是先把包弄进去。stress 离线安装解决的就是这件小事把一个小体量的压测工具塞进没有外网出口的 CentOS 机器用手头现有的资源把 CPU、内存、磁盘 IO 的负载拉起来验证新到货机器的散热、电源和老旧硬件的隐性故障。它适合三类人验收服务器的运维、排查偶发卡死的后端开发、需要在内网复现高负载问题的测试同学。工具本身很简单麻烦的全在包和依赖上。2. 先把依赖摸清楚stress 的压力模型、参数语义与三种离线包来源2.1 stress 怎么造压力四条 worker 路径的实际差别stress 的工作模型很不花哨主进程按参数 fork 出一批 worker 子进程每个 worker 进入一种死循环主进程负责收集退出状态wait()--timeout到点后给所有子进程发终止信号。它没有复杂的调度也不做负载建模所以压出来的曲线是「方波」而不是「正弦波」——这一点必须先接受否则拿它去做业务相似负载的仿真会失望。四条路径各自的循环体决定了它能测什么worker 类型参数循环体做什么压的是什么CPU--cpu N反复调用sqrt()内部做忙等计算单核算力、散热、主频降频行为内存--vm Nmalloc后逐页写入再free内存带宽、页回收、OOM 边界IO--io N反复调用sync()内核回写路径、脏页排队磁盘--hdd N在临时目录写文件再 unlink真实落盘带宽、inode 与元数据开销值得单独说一句--io它压的不是磁盘本身是sync()这条系统调用路径。很多人在虚拟机上一跑--io 8发现 iostat 的%util纹丝不动就断定工具没用——其实脏页早被内核刷下去了磁盘根本没形成队列。要打出磁盘 IO得靠--hdd。这个区别在后面的避坑里还会再撞一次。另一组容易被忽略的参数是节奏控制--backoff N让每个 worker 启动间隔 N 微秒避免瞬间 fork 出一堆进程把fork本身变成压力源--vm-hang N让内存 worker 分配完挂起 N 秒再释放用它能把「持续占用」和「反复分配释放」两种模式区分开。默认的--vm-hang 0是不挂起也就是最凶的 malloc/free churn。2.2 一台没网的机器能给你什么glibc、gcc、rpm 的底牌盘点动手前先花五分钟盘家底这五分钟通常能省掉后面半小时的报错。# 1. 系统版本和架构决定了你该拿 el7 还是 el8、x86_64 还是 aarch64 的包 cat /etc/centos-release uname -m # 2. glibc 版本跨发行版拿包翻车基本都翻在这 rpm -q glibc ldd --version | head -1 # 3. 有没有编译工具链决定源码编译这条路走不走得通 for c in gcc make ld; do printf %-6s: $c; command -v $c /dev/null $c --version | head -1 || echo MISSING; done # 4. 本机已有的仓库看看是不是已经藏了一个本地源 yum repolist all 2/dev/null | head -20这四条命令输出完路线基本就定了gcc齐全就走源码编译缺工具链但手上有 ISO 就先搭本地源两样都不占就只能靠一台同版本的有网机器把 rpm 打下来。rpm -q glibc那一步别跳。CentOS 7 的 glibc 是 2.17CentOS 8 是 2.28从 8 上抓的包扔到 7 上装的时候会甩一句libc.so.6(GLIBC_2.28) is needed看着像缺文件本质是符号版本对不上补文件没用只能换包。2.3 离线包的三种来源与选型取舍第一种直接取发行版仓库里的二进制 rpm。stress 不在 CentOS 的 base 仓库里它在 EPEL 里包名形如stress-1.0.4-1.el7.x86_64.rpm。找一台同版本、同架构、能出网并且已经配了 EPEL 的机器yumdownloader或者yum install --downloadonly把包拉到本地目录再拷进内网。这条路的优点是快、装完即用缺点是包跟着发行版走el7的包塞不进el8必须版本对齐。第二种源码包自己编。上游发布的是stress-1.0.4.tar.gz两百多 KBconfiguremake两步就完。优点是完全不挑发行版只要 glibc 版本别低得离谱缺点是目标机得有 gcc 和 make而这恰恰是很多最小化安装的机器缺的东西。第三种先搭本地源再用 yum 装。手上有 CentOS 安装 ISO 的话把 ISO 挂到/mnt当 file 协议仓库gcc、make、sysstat这些编译和观测要用的包一次性装齐。三种里这种最稳因为它顺手把后面观测指标要用的sysstat、pidstat也解决了不用再单独折腾。提示选型的第一原则是「目标机的 glibc 版本说了算」不是「哪个包新用哪个」。压测机往往就是生产机版本错配引入的库冲突比压不出效果更麻烦。3. 两条落地路线rpm 直装与源码编译的可复制步骤3.1 rpm 直装装前预检与装后验证拿到 rpm 之后别急着-ivh先问它想要什么。# 把包放到目标机的固定目录后面所有操作都基于这个路径 mkdir -p /opt/soft cd /opt/soft # 预检一这个包依赖哪些能力capability rpm -qpR stress-1.0.4-1.el7.x86_64.rpm # 预检二逐个确认依赖在本机是否已满足输出为空说明全齐 rpm -qpR stress-1.0.4-1.el7.x86_64.rpm \ | awk !/^rpmlib/ !/^\// \ | while read -r cap; do rpm -q --whatprovides $cap /dev/null 21 || echo MISSING: $cap donerpm -qpR读的是包头的依赖声明不需要安装就能看。第二段用awk把rpmlib(...)这类 rpm 自身的内部能力过滤掉——它们不是真依赖留着会刷一屏假阳性。剩下逐条喂给rpm -q --whatprovides有输出就是本机已有包提供了这个能力没输出才是真缺。这个循环跑完一行MISSING都没有安装就是十拿九稳的事。# 正式安装-v 显示过程-h 显示进度条 rpm -ivh stress-1.0.4-1.el7.x86_64.rpm # 验证三连包在不在、命令在哪、参数认不认 rpm -q stress command -v stress stress --help 21 | head -15rpm -q stress输出stress-1.0.4-1.el7.x86_64说明包数据库里已经登记command -v确认/usr/bin/stress在 PATH 上stress --help把 usage 打出来说明动态链接没坏——有些残缺环境里二进制在、一跑就error while loading shared libraries--help这一下正好能提前暴露。最后跑一个三十秒的小压测确认真的能拉负载# 2 个 CPU worker跑 30 秒后自动退出--verbose 打印每个 worker 的 pid 和退出状态 stress --cpu 2 --timeout 30s --verbose参数含义--cpu 2是 fork 两个 cpu worker不是「用 2 个核」实际占用取决于调度器把它们扔到哪--timeout 30s到点后主进程向所有子进程发SIGTERMworker 收到后打一行exited with status--verbose建议在第一次验证时都带上它会把 pid 打出来后面pidstat要按 pid 抓数据时用得上。3.2 源码编译configure 之前的三个前置条件源码这条路的前置条件就三个gcc、make、以及能正常工作的 ld。判断方法在 2.2 里已经给过这里补一个常见误判——gcc在 PATH 上不代表能编译很多最小化安装的机器只装了gcc的元包缺glibc-devel一编就报stdio.h: No such file or directory。# 补一个更硬的检查试着编一个最小 C 程序 printf #include stdio.h\nint main(){printf(ok\\n);return 0;}\n /tmp/t.c gcc /tmp/t.c -o /tmp/t /tmp/t || echo 工具链不完整需要 glibc-devel这个自检比看版本号靠谱得多。头文件、链接器、启动文件任何一环缺失这里立刻暴露。工具链齐了就开始编# 解压到 /usr/local/src这是放源码的常规位置 tar -xzf /opt/soft/stress-1.0.4.tar.gz -C /usr/local/src cd /usr/local/src/stress-1.0.4 # --prefix 指定安装根装到 /usr/local 下不污染系统目录 ./configure --prefix/usr/local # -j 的取值别超过核数超了只会互相抢内存 make -j$(nproc) # 安装需要写 /usr/local/bin 的权限普通用户配合 sudo 或改 --prefix 到家目录 make install /usr/local/bin/stress --help 21 | head -5--prefix这个参数值得多说一句没有 root 的机器上改成--prefix$HOME/.local一样能装装完把$HOME/.local/bin加进 PATH 就行。压测常常是在别人负责的机器上临时做能不动系统目录就不动事后清理也简单rm -rf对应目录即可不留包管理器的残留记录。make -j的数字不是越大越好。压测机本身可能已经在跑业务编译期把核占满会让业务抖动编译和压测是两件事别混在一起。3.3 缺工具链的兜底方案拿安装 ISO 搭一个本地 yum 源最尴尬的局面是机器没网、没 gcc、手上只有一个 CentOS 安装 ISO。这个局面其实好解ISO 里的Packages目录本身就是一个完整的仓库。# 挂载 ISO/dev/sr0 是虚拟光驱的常规设备名ISO 文件则用 -o loop mkdir -p /mnt/iso mount -o loop /opt/iso/CentOS-7-x86_64-DVD-2009.iso /mnt/iso # 物理光驱场景换成mount /dev/sr0 /mnt/iso # 确认仓库元数据在不在repodata 目录存在才说明这是个可用源 ls -d /mnt/iso/repodata仓库定义文件写起来就四行关键在于baseurl用file://协议指向挂载点cat /etc/yum.repos.d/local-iso.repo EOF [local-iso] nameLocal ISO Repository baseurlfile:///mnt/iso enabled1 gpgcheck0 EOF # 清缓存重建然后只启用本地源装包避免 yum 去够外网超时 yum clean all yum --disablerepo* --enablerepolocal-iso install -y gcc make glibc-devel--disablerepo*这一步是血泪经验内网机器上通常还留着几个指向外网的 repo 文件不清掉的话 yum 会先尝试连它们每个超时几十秒装一个包等十分钟。显式禁用再启用本地源整个过程几秒钟结束。gpgcheck0是因为没导入 ISO 的 GPG key属于内网自用场景的常规取舍如果合规上要求校验把 key 从 ISO 里导出来rpm --import之后改回gpgcheck1就行。装完glibc-devel之后回到 3.2 的编译流程整条链路就通了。这套本地源还有一个附带好处sysstat提供pidstat、sar、tar、gzip这些观测和打包工具都能一并装齐后面第 4 章要用的观测手段不再缺胳膊少腿。4. 压测方案怎么写CPU、内存、IO 三类负载的参数标定与观测口径4.1 压 CPUworker 数跟核数的对齐方式CPU 压测最容易犯的错是「数字拍脑袋」。--cpu 4在 4 核机器上是满载在 32 核机器上是挠痒痒。先把核数取出来# 逻辑核数也就是调度器眼里的 CPU 个数 nproc # 物理核数每颗物理 CPU 的 core 数之和排除超线程后的真实并行度 lscpu | awk /^CPU\(s\)|^Core\(s\) per socket|^Socket\(s\)/{print}nproc给的是逻辑核数包含超线程。压测标定一般用两档--cpu $(nproc)打满逻辑核观察频率是否掉到基频以下、温度是否冲上限--cpu $(( $(nproc) / 2 ))对应物理核数在开启超线程且核数翻倍的机器上大致成立观察有没有单核跑满导致的长尾。# 打满全部逻辑核持续 5 分钟把每个 worker 的启动/退出都打出来 stress --cpu $(nproc) --timeout 300s --verbose参数说明--timeout的单位固定是秒写5m会被当成非法参数直接报 usage这是新手第一个卡点。--verbose在这里的用处是确认 worker 数量真的等于nproc——如果机器上有人配了 cgroup 的cpu.max或者用了容器限额你会看到 worker 都起来了但%CPU上不去这时候问题不在 stress。判定 CPU 压测是否有效的标准不是「进程在跑」而是三条同时成立vmstat的r列运行队列稳定大于等于核数id接近 0 而sy不高sy高说明瓶颈在系统调用不在算力us占到 90% 以上。只满足第一条可能是在等锁只满足第三条可能是被限流了。4.2 压内存总量、增量与留多少余量内存压测的核心参数只有两个--vmworker 数和--vm-bytes每个 worker 分配多少。总压力等于两者相乘这个乘法关系是很多人漏算的地方——写--vm 4 --vm-bytes 2G压的是 8G不是 2G。先算清楚本机有多少可用的字节数# 用字节输出避免 MB/GB 换算误差 free -b | awk /^Mem:/{printf total%d\navailable%d\n, $2, $7} # 留 20% 余量后的单 worker 字节数4 个 worker 平分 free -b | awk /^Mem:/{printf per_worker%d\n, int($7*0.8/4)}$7是available列比free列更准因为它把可回收的 page cache 也算进去了。留 20% 余量不是保守是必须——压测机上通常还跑着 sshd、监控 agent、日志采集把内存压到一根毛都不剩最先被 OOM killer 挑中的往往就是它们机器直接失联你连结果都收不回来。# 4 个 worker每个 1GiB1073741824 字节持续 5 分钟 stress --vm 4 --vm-bytes 1073741824 --timeout 300s --verbose注意这里写的是纯字节数。为什么不用1G这种写法第 5 章会专门讲那是一个能让整个压测白做的坑。如果要测「内存常驻」而不是「分配释放抖动」加上--vm-hang# 分配后挂起 60 秒再释放模拟长驻内存对象 stress --vm 4 --vm-bytes 1073741824 --vm-hang 60 --timeout 300s--vm-hang 60的效果是 worker 分配完内存后 sleep 60 秒期间内存一直被占着。这个模式更接近真实业务的堆占用也更容易把机器推到 OOM 边缘——因为释放被延后了峰值占用会叠加。4.3 压磁盘 IO--hdd和--io到底选哪个回到 2.1 的结论--io压的是sync()调用路径--hdd压的是真实落盘。要做磁盘验收用--hdd。# 2 个 hdd worker每个写 2GiB 的临时文件持续 5 分钟 stress --hdd 2 --hdd-bytes 2147483648 --timeout 300s --verbose--hdd-bytes同样是纯字节数。这个参数决定每个 worker 单个临时文件的大小写满之后 unlink 再重来。文件大小要大于目标盘的写缓存否则全程都在内存里转iostat 上看不到多少wMB/s。一般取目标盘容量的 1%5%或者干脆固定 2GiB。# 混合场景CPU 打满 磁盘持续写观察 IO 等待对算力的挤压 stress --cpu $(nproc) --hdd 2 --hdd-bytes 2147483648 --timeout 300s这个组合是验收里最有用的一档。单压 CPU 时机器可能很稳一旦叠上磁盘写vmstat的wa列会告诉你真相wa超过 20 说明有相当比例的 CPU 时间在等 IO这时候机器的实际吞吐是要打折的。新机器验收如果只跑单压这个折扣是看不出来的。4.4 观测口径三组数据怎么读才算读懂了压测命令本身只有一行判断结果靠的是旁边的观测。三组数据足够覆盖绝大多数场景。第一组vmstat看全局。# 每秒采样一次共 10 次 vmstat 1 10关键列r是运行队列长度持续大于核数说明 CPU 排队si/so是换入换出非 0 说明内存已经压到 swap这时候内存压力的结论要打问号wa是 IO 等待占比ussy接近 100 而id接近 0 才算 CPU 打满。第二组pidstat看进程。# 按 pid 抓 stress 所有子进程的 CPU 和内存pidstat 来自 sysstat 包 pidstat -p $(pgrep -d, stress) 1 5pgrep -d,把多个 pid 用逗号拼起来喂给-p一次抓全。输出里的%CPU是单核百分比100 表示占满一个核4 核机器上四个 worker 各自接近 100 才叫打满。如果 sysstat 装不上退而求其次用top -b -n 1 -p $(pgrep stress | head -1)。第三组iostat看磁盘。# -x 扩展统计2 秒一次共 5 次重点看 %util 和 await iostat -x 2 5%util接近 100 说明设备饱和await是平均等待毫秒数机械盘上到几十毫秒就开始影响体验SSD 上到几毫秒就该警觉。这两个数在--hdd和--io下的表现差异极大正好可以用来验证你选的参数是不是压到了想压的地方。注意观测本身有开销。vmstat 1和iostat -x 2加起来对结果的影响可以忽略但如果把采样间隔设成 0.1 秒采样进程自己就会变成负载的一部分测出来的数就不干净了。5. 五个真实翻车点从 vm-bytes 单位到 OOM 杀掉 sshd 的排查路径5.1 现象内存 worker 起来了内存却纹丝不动现象stress --vm 4 --vm-bytes 1G跑起来top里能看到四个 stress 进程但free的used几乎没变化vmstat的si/so全是 0机器一点都不卡。原因--vm-bytes的解析走的是纯数字路径只认字节数。写1G时解析器读到G就停了最终拿到的值是1——每个 worker 分配 1 字节。进程确实在跑也确实在做 malloc/free压的是分配器的元数据开销跟内存容量完全没关系。这个坑极其隐蔽因为命令不报错进程不退出看起来一切正常。解决一律换算成字节数或者用awk/shell 算。1GiB 10737418242GiB 2147483648。稳妥的做法是让脚本自己算# 从 free 取可用字节按 80% 和 worker 数算出每个 worker 的字节数 workers4 per$(free -b | awk -v w$workers /^Mem:/{printf %d, int($7*0.8/w)}) echo per_worker_bytes$per stress --vm $workers --vm-bytes $per --timeout 300s以后再看到「内存压不上去」第一反应先echo一下传进去的数字比怀疑内核快得多。5.2 现象压测跑到一半 SSH 断连机器彻底失联现象stress --vm 8 --vm-bytes 接近物理内存的值跑到第三分钟终端卡死重连提示连接被拒绝ping 通但 SSH 上不去只能去机房按电源。原因内存压到没有余量内核的 OOM killer 触发。它的评分机制是「谁占的内存多就挑谁」听起来应该杀 stress但实际被杀顺序取决于oom_score_adjsshd、监控 agent 这些常驻进程的战绩往往比新起的 stress 更高因为它们活得久、算分时占优。结果就是压测工具没事管理通道被端了。解决三层防护。第一层压测总量不超过available的 80%这个在 4.2 里已经算过。第二层压测前给关键进程降权把 sshd 保护起来# 给 sshd 一个极低的 OOM 分数让它不容易被选中 pgrep -x sshd | while read -r p; do echo -1000 /proc/$p/oom_score_adj 2/dev/null; done第三层如果是长跑压测别在交互式 SSH 里挂着跑用nohup或者systemd-run放到后台输出重定向到文件断连了也不影响。# 后台长跑输出落盘断连不中断--scope 让它跑在独立 cgroup 里方便整体清理 systemd-run --scope --unitsoak-test -p MemoryMax80% \ stress --vm 4 --vm-bytes 1073741824 --timeout 3600s-p MemoryMax80%是给 cgroup 加内存上限让内核对 stress 这个 cgroup 先做回收压力不会溢出到系统全局。5.3 现象--hdd跑了十分钟iostat 上没有写流量现象stress --hdd 4 --hdd-bytes 2147483648跑着iostat -x里的wMB/s一直是零点几%util个位数磁盘根本没被压到反而是free的内存在往下掉。原因--hdd的临时文件写在/tmp下。很多服务器尤其是容器宿主机和云主机的/tmp挂的是 tmpfs本质是内存文件系统。写进去的字节全在 RAM 里一次磁盘 IO 都没发生反而把内存吃掉了一大块。这个现象在内存压测和 IO 压测混着跑的时候特别迷惑容易得出「IO 性能极好」的错误结论。解决先确认/tmp的挂载类型再决定怎么绕。# 看 /tmp 是 tmpfs 还是真实块设备 findmnt -T /tmp -o TARGET,SOURCE,FSTYPE,SIZE # 如果是 tmpfs找一块真实盘出来比如数据盘挂载点 /data df -hT | awk $2!tmpfs $2!devtmpfs{print $1, $2, $7}确认是 tmpfs 之后有两条路一是把压测目录切到真实盘上--hdd本身不支持指定路径但可以cd到目标目录再跑部分打包版本的临时文件是相对当前工作目录创建的跑之前先用一条小命令确认实际落点二是干脆换stress-ng它提供了--temp-path参数能显式指定落盘目录。离线环境装stress-ng依赖更多如果只是验收磁盘dd其实也够用但dd是单线程顺序写跟真实业务的并发随机写差得远别拿它当唯一依据。5.4 现象--timeout到点了ps里还是一片 stress 进程现象带了--timeout 60s一分钟过去主进程退了ps aux | grep stress还能看到一堆 worker。原因--timeout到期后主进程向子进程发SIGTERMworker 收到信号后要走到下一个检查点才退出。CPU worker 的循环体极短响应很快但内存 worker 如果正卡在malloc大块内存或者 page fault 上SIGTERM的处理会被推迟。更常见的情况是主进程自己被kill -9了——比如 SSH 断连触发 SIGHUP主进程直接死子进程被 init 收养成了孤儿继续跑。解决清理用pkill别用kill逐个找。# 先看还有多少残留 pgrep -a stress # 温和终止给 5 秒缓冲 pkill -TERM -x stress; sleep 5 # 还剩下就强杀注意 -x 是精确匹配进程名别把 grep 自己带上 pkill -KILL -x stress-x这个参数很关键。不带的话pkill stress会匹配命令行里含stress的所有进程包括正在编辑的vim stress.log那就要出事故了。压测机上跑着别的服务时精确匹配是保命的习惯。5.5 现象rpm -ivh报GLIBC_2.28 not found现象从另一台机器上拷了个 rpm 过来装的时候报libc.so.6(GLIBC_2.28)(64bit) is needed by stress-...。原因包是从更高版本的发行版上取的。CentOS 7 的 glibc 是 2.17包在编译时链接到了 2.28 才有的符号本机的动态库提供不了这些符号版本。缺的不是文件是符号的版本标签所以哪怕你把/lib64/libc.so.6从别的机器拷过来也没用反而会搞坏系统。解决换包不要试图补库。# 确认本机 glibc 版本据此决定该拿哪个 el 版本的包 rpm -q glibc # 如果没有匹配的 rpm 可用直接走源码编译第 3.2 节 # 源码在目标机上编译时链接的是本机 glibc天然不会有这个问题判断依据很简单el7的包只能在 el7 上用el8的包只能在 el8 上用跨大版本一律走源码。这条规则在离线环境里比什么都重要因为一旦装错卸载时rpm -e可能因为依赖关系被卡住反而留下烂摊子。6. 把一次性压测变成例行验收阶梯加压脚本与结果沉淀单次压测最大的问题是结论不可比。今天压 5 分钟说「很稳」明天换个参数压 5 分钟说「有点抖」两次数据没有共同基准讨论就变成玄学。我的做法是把压测做成固定档位的阶梯每档固定时长、固定采样、固定落盘机器之间的结果可以直接横向比。#!/bin/bash # soak.sh —— 阶梯加压25% / 50% / 75% / 100% 四档每档 5 分钟 # 用法./soak.sh /var/log/soak set -u LOG_DIR${1:-/var/log/soak} mkdir -p $LOG_DIR LOG$LOG_DIR/soak-$(date %Y%m%d-%H%M).log CORES$(nproc) echo # host$(hostname) cores$CORES start$(date %F %T) $LOG for pct in 25 50 75 100; do n$(( CORES * pct / 100 )) [ $n -lt 1 ] n1 echo $(date %F %T) cpu ${pct}% workers$n $LOG # 后台起压测前台做采样避免采样被压测阻塞 stress --cpu $n --timeout 300s --quiet spid$! for _ in $(seq 1 10); do sleep 30 vmstat 1 1 | tail -1 $LOG done wait $spid 2/dev/null # 每档结束记录一次内存和负载余量作为档间恢复的判断依据 free -m | awk /^Mem:/{printf free_mb%s avail_mb%s\n, $4, $7} $LOG done echo # done $(date %F %T) $LOG脚本的逻辑不复杂但有几个设计取舍值得说。stress放后台、采样放前台是因为--timeout期间主进程一直占着终端前台采样会被压住sleep 30每档采 10 次五次能覆盖整档的后半段避开启动瞬间的抖动每档结束记一次free是为了看档位回落时内存有没有回到基线——回不去说明有泄漏或者 page cache 没释放这比压测期间的峰值更值得警惕。结果沉淀成一张表比盯着屏幕看更有说服力档位worker 数r 均值us%sy%wa%可用内存 MB判定25%22.024106200正常50%44.149216100正常75%66.373325950正常100%89.892635700队列溢出最后一行的r9.8大于 worker 数 8说明出现了额外排队可能是后台的监控 agent 在抢 CPU也可能是超线程下的调度争抢。这个信息单跑一次满载是看不出来的只有阶梯对比才能定位到「从哪一档开始不线性」。从那以后我每次进场压测前都会强制走一遍rpm -qpR和free -b这两步参数里的字节数一律用命令算、不用手敲跑完必pkill -x扫一遍残留。这三件事花不到两分钟但省下来的返工时间远不止两小时。希望帮到你。本文还有配套的精品资源点击获取