vmstat 输出中 r 列长期高于 CPU 核心数代表 CPU 计算资源不足，进程排队严重；b 列升高通常代表进程处于不可中断睡眠状态，指向 I/O 瓶颈或资源等待。
先说结论：r 列过高说明 CPU 忙不过来，b 列过高说明进程在等 IO 或其他资源。
- 先定位：对比 r 值与 CPU 逻辑核心数，确认是否持续超标。
- 先做：r 高需优化代码或扩容 CPU，b 高需排查磁盘 IO 或内存交换。
- 再验证：结合 wa 值和负载平均值，确认瓶颈类型是否匹配。
命令速用版
使用以下命令快速查看系统状态，建议间隔 1 秒连续观察：
vmstat 1 nproc uptime
nproc 用于获取 CPU 核心数，uptime 用于对比负载平均值。
为什么会这样
r 列代表运行队列长度，b 列代表阻塞进程数，两者共同构成系统负载的本质。
r 列包含正在运行和就绪等待 CPU 调度的进程总数，直接反映 CPU 压力。当 r 值超过 CPU 核心数，意味着有进程无法立即获得 CPU 时间片。b 列在现代 Linux 中通常表示处于不可中断睡眠状态（TASK_UNINTERRUPTIBLE）的进程，常见于等待磁盘 I/O 完成。系统负载平均值本质上是 r 与 b 在时间窗口内的平滑均值，因此 vmstat 的这两列是理解负载的核心。
分步处理
1. 确认 CPU 核心数：运行 nproc 命令获取逻辑核心数，作为 r 列的基准线。
2. 观察 r 列趋势：执行 vmstat 1 连续观察，若 r 值长期大于核心数，说明 CPU 资源不足，需增加 CPU 或优化任务调度。
3. 检查 b 列与 wa 值：若 b 值升高且 wa（I/O 等待 CPU 时间百分比）较高，说明存在 I/O 瓶颈。部分资料指出 wa 高过 30% 时 I/O 压力高。
4. 排查负载类型：综合观察 r、b、wa 及 id（空闲 CPU），判断是 CPU 密集型还是 I/O 密集型负载。
怎么验证是否生效
优化后再次运行 vmstat 1，观察 r 列是否回落至核心数以下，b 列是否清零或显著降低。同时使用 top 或 uptime 检查负载平均值是否下降，系统响应速度是否恢复。
常见坑
1. 瞬时峰值误判：短暂 r 值高可能正常，长期超过核心数才必须干预。
2. b 列定义差异：较老版本 vmstat 中 b 表示等待资源的进程数，现代 Linux 中 b 列实际上表示处于不可中断睡眠状态的进程数，解读时需以内核和 procps 版本为准。
3. 负载平均值误区：vmstat 命令本身不直接显示负载平均值，该指标需通过 uptime、top 或/proc/loadavg 获取，不要混淆。
常见问题
top 命令的 load average 和 vmstat 的 r 列和 b 列有什么关系？
系统负载平均值本质上是 r 列（运行队列）与 b 列（阻塞进程）在时间窗口内的平滑均值。
r 列高但 us（用户态 CPU）不高是什么原因？
可能进程处于就绪状态但未被调度，或存在内核态竞争，需结合 sy（内核态 CPU 占比）分析。
b 列一直很高但 wa 不高怎么办？
可能进程在等待非磁盘 I/O 资源，如内存交换或网络锁，需检查 swpd 虚拟内存使用情况。
参考来源
- vmstat 1 输出里哪几列最能反映系统真实负载？为什么 r 和 b 值特别关键？
- 利用 vmstat 命令监控系统 CPU 时，r 列表示运行和等待 cpu 时间片的进程数，这个值如果长期大于系统 CPU 的个数，此情况说明了什么问题？
- top 命令的 load average 和 vmstat 的 r 列和 b 列的关系是什么？区别又是什么？
- 性能测试 - vmstat 解析
- Linux 命令行中 vmstat 命令的实用技巧