要看真实负载波动，必须监控 vmstat 的 r 和 b 列之和或 /proc/loadavg 第四字段斜杠前的数值，因其反映瞬时就绪与阻塞进程数，比 loadavg 三分钟均值更及时准确；b≥2 通常表明 I/O 阻塞。
单看 uptime 或 top 里那三个数字，根本看不出波动——它们是指数衰减加权平均值，1 分钟值抖动大、15 分钟值又太滞后。真要看“波动”，得抓瞬时排队行为，而不是等内核慢悠悠算完再给你一个平滑数。
用 vmstat 实时抓 r 和 b 列的秒级变化
真正反映“此刻有多少进程在排队”的，是 vmstat 的 r（就绪态）和 b（不可中断态，即 D 状态）两列之和。这个和值每秒刷新一次，比 /proc/loadavg 第一列更及时，也更贴近真实压力源。
-
vmstat 1 10连续采样 10 秒，观察r和b是否持续 > CPU 逻辑核数（可用nproc查） - 若
b长期 ≥ 2，基本可断定是磁盘或 NFS 卡住，不是 CPU 问题 -
r + b值 ≈/proc/loadavg第一字段（1 分钟负载）的瞬时映射，但无延迟 - 注意别只盯
wa列：它滞后，且为百分比；b是绝对进程数，更早暴露 I/O 阻塞
脚本化采集时别只读 /proc/loadavg 前三列
自动化监控脚本如果只写 awk '{print }' /proc/loadavg，等于主动丢掉关键上下文。第四字段（如 2/124）才是当前真实就绪+阻塞进程数的快照，斜杠前那个数字就是 r + b 的实时值。
- 推荐写法：
awk '{print $1, $4}' /proc/loadavg，输出类似0.42 2/124 - 进一步提取瞬时排队长度：
awk '{split($4, a, "/"); print a[1]}' /proc/loadavg - 该值可用于告警阈值判断，比如连续 3 次 >
nproc输出值，才触发高负载告警 - 直接解析
/proc/loadavg比调用uptime更轻量，无子进程开销
watch -n 1 不适合看真实波动
watch -n 1 uptime 看起来是每秒刷新，但 uptime 自身调用的是内核缓存的 loadavg 值，更新频率由内核定时器控制（通常 5 秒一次），你看到的“每秒变化”很多是重复值或插值，不是真实采样。
- 真正需要秒级响应时，必须用
vmstat 1或轮询/proc/loadavg的第四字段 -
watch -d -n 1 'cat /proc/loadavg | awk "{print \$1, \$4}"'可高亮变化，但仍是读文件，比vmstat多一层解析开销 - 在低配机器上频繁 fork
watch+cat+awk可能反成干扰源
波动的本质是瞬时队列长度的变化，不是平均值曲线的起伏。很多人盯着 load average: 4.2, 1.8, 0.9 说“负载在下降”，却没注意到 vmstat 里 b 从 0 突然跳到 5 并卡住 3 秒——这才是 I/O 毛刺的真实形态。抓波动，得向下沉一层，看 r 和 b，而不是仰头看平均数。
