Linux vmstat 的 run queue 长期升高说明什么

我排查 Linux 负载时，最容易被误读的是 vmstat 的 r 列：它不是 CPU 使用率，也不是“已经跑满了几个 CPU”。它表示当前可运行、正在运行或等待运行时间的任务数量。长期升高通常说明调度竞争存在，但真正原因还要看 CPU 是否忙、任务是否被限制在少数核心，以及是否把 I/O 阻塞混进了负载判断。

先读懂 vmstat 的 r：它不是 CPU 百分比

vmstat 的进程区通常从 r 和 b 开始。r 是正在运行或等待 CPU 时间的 runnable 进程数，b 是等待 I/O 完成而阻塞的进程数。也就是说，r=8 只说明采样瞬间有 8 个可运行任务，不能单独证明 CPU 已经饱和。

先把几个字段放在一起读：us 是用户态 CPU 时间，sy 是内核态 CPU 时间，id 是空闲时间，wa 是等待 I/O 的时间。比如 r 高且 us+sy 也高，更像 CPU 供给不足；r 不高但 b、wa 高，则应先看存储、网络文件系统或其他 I/O。

用连续采样确认是瞬时尖峰还是持续排队

单次输出可能只是定时任务、编译、GC 或流量抖动留下的瞬间。我的习惯是先固定间隔采样，再看连续几行是否同方向变化：

# 每秒采样 5 次；-y 忽略自启动以来的第一行平均值
vmstat -y 1 5

如果只有一行的 r 突然变大，先不要扩容；如果多次采样都明显高于逻辑 CPU 数，同时 id 很低，才有持续 CPU 竞争的证据。注意第一行在某些 vmstat 实现中是自启动以来的平均值，和后续采样周期不是同一含义。

把 r 与 CPU 核数、load average 和进程状态对上

“r 长期高”要和机器规模一起解释。4 个逻辑 CPU 上长期有 8 个 runnable 任务，排队压力通常比 32 个逻辑 CPU 上有 8 个更值得关注。再看：

# 查看每个 CPU 的忙闲分布，避免平均值掩盖单核过载
mpstat -P ALL 1 3

# 查看负载平均值、当前 runnable 实体数和总实体数
cat /proc/loadavg

/proc/loadavg 的前三个数字是 1、5、15 分钟平均值，统计对象包括可运行的 R 任务和等待磁盘 I/O 的 D 任务，所以 load average 高并不等于 vmstat 的 r 高。若 r 和 id 同时偏高，优先怀疑任务被 CPU 亲和性、cpuset 或容器配额限制在少数核心；若 b、wa 和 D 状态一起升高，则转向 I/O 路径。

沿着占用 CPU 的进程继续定位

确认是 CPU 竞争后，不要直接给所有进程加 nice。先找出进程、线程和它们实际能使用的 CPU：

# 按 CPU 使用率查看进程状态；R 是 running/runnable，D 通常与不可中断 I/O 有关
ps -eo pid,ppid,stat,psr,pcpu,comm --sort=-pcpu | head -n 15

# 查看指定进程当前允许运行的 CPU 集合；替换为实际 PID
taskset -pc PID

# cgroup v2 中可查看 CPU 配额；max 表示不设周期配额
cat /sys/fs/cgroup/cpu.max

如果只有一个核心满载而其他核心空闲，先检查进程的 affinity、线程池分配和容器 cpuset；如果所有核心都忙，再看是否是编译、压缩、加密或业务线程数过多。cpu.max 受限时，宿主机还有空闲 CPU 也不代表容器能立即获得更多时间。

常见问题与处理边界

r 超过 CPU 核数就一定要扩容吗？

不一定。短时超过可能是正常突发；持续超过且业务延迟、id 和调度等待同步恶化，才需要在降并发、优化热点、调整 CPU 配额和扩容之间做选择。

load average 高，为什么 vmstat 的 r 不高？

因为 load average 还会计入等待磁盘 I/O 的 D 状态任务。此时看 b、wa 和进程状态，比盯着 r 更有效。

应该先调 nice 还是先查 affinity？

先查 affinity、cpuset 和 cgroup 配额，再决定调度优先级。nice 只能改变竞争顺序，不能增加被限制的 CPU 容量。

所以，Linux vmstat 的 run queue 长期升高，最准确的结论是“可运行任务持续在竞争调度时间”。把它和 CPU 分布、R/D 状态、亲和性及配额逐项对齐，才能把数字转成真正可执行的处理动作。