r 值表示运行队列长度，即正在运行或等待 CPU 调度的进程总数；若长期高于 CPU 核心数，说明调度拥堵，需结合 D 状态进程、iostat、中断统计、cgroup throttling 等多维度排查真实瓶颈。

看懂 r 值到底在等什么

r 是 vmstat 中「运行队列长度」，它统计的是**正在 CPU 上运行 + 等待 CPU 调度的进程总数**。注意：它不区分用户态/内核态，也不管进程是不是卡在 I/O、锁、内存分配或中断里——只要没被调度出去，就还在队列里。所以 r 长期高于 CPU 核心数（比如 8 核服务器 r > 8），说明调度器“排不上号”，但 top 里看不到高 CPU 进程，恰恰说明这些进程根本没机会跑满 CPU，而是被别的东西拦住了。

重点排查 D 状态进程和不可中断等待

当进程因磁盘 I/O、NFS 挂载、内核锁或硬件驱动阻塞时，会进入 D（Uninterruptible Sleep）状态。这类进程：
• 不响应信号（kill -

9 无效）
• 不计入 top 的 CPU 使用率（因为没执行指令）
• 却持续占据 r 队列位置
• 在 ps aux 输出中 STATE 列显示为 D

• 快速检查：ps -eo stat,pid,comm | grep "^D"
• 结合 vmstat 1 观察 b 列（阻塞进程数）是否同步升高；若 r 和 b 都高，基本锁定 I/O 或内核路径阻塞
• 用 iostat -x 1 看 %util 是否接近 100%、await 是否远超 10ms（SSD）或 50ms（HDD）

别漏掉中断和内核线程的“隐形消耗”

CPU 负载高但用户进程不占 CPU，常见于高频硬件中断（如网卡收包、NVMe 驱动、USB 设备）或内核线程密集争抢资源。这类负载不会出现在 top 默认视图，但会推高 vmstat 的 in（每秒中断数）、cs（上下文切换）和 sy（系统态 CPU）。

• 查中断分布：watch -n1 'cat /proc/interrupts | sort -k2nr | head -10'，关注某 CPU 上某设备中断是否突增
• 查内核线程：top -H -p $(pgrep kthreadd) 或 ps -eLh o pid,tid,class,rtprio,ni,pri,psr,pcpu,state,comm | awk '$11=="R" || $11=="D" {print}' | sort -k7nr | head -10
• 确认 irqbalance 是否启用：systemctl is-active irqbalance；若关闭且中断集中在一个核，r 高就非常典型

短生命周期进程和 cgroup 限制也会“藏”负载

频繁 fork/exit 的进程（如 CGI 脚本、容器健康检查、日志轮转）可能在 top 刷新间隔（默认 3 秒）内一闪而过，导致“看不见但压得死”。另外，如果进程受 cgroup CPU quota 限制（如 cpu.max = 10000 100000），它会反复被 throttled，表现为调度队列积压，但单次运行时间极短，top 统计不到显著占用。

• 捕获瞬时进程：pidstat -u 1 10（比 top 更细粒度）或 atop -r /var/log/atop/atop_$(date +%Y%m%d) -r 1（需提前开启 atop 日志）
• 检查 cgroup 限频：cat /sys/fs/cgroup/cpu,cpuacct/*/cpu.stat 2>/dev/null | grep throttled，有非零值即存在节流
• 验证是否是调度延迟本身：perf sched latency -s max 可输出最高调度延迟及对应进程

真正难缠的不是 r 高，而是它背后混着 I/O 阻塞、中断风暴、内核锁竞争、cgroup 节流等多种机制——必须靠 vmstat 定向、ps/iostat/perf 多点交叉，才能揪出那个“不动声色却堵死通道”的元凶。