运行队列长度（r）是反映CPU调度压力的核心指标，r值持续高于CPU核心数表明进程排队等待，导致响应时间上升；可通过vmstat、sar -q或/proc/loadavg实时查看，需结合响应时间与调度延迟工具归因分析。
运行队列长度（run queue length，常记为 r）是 Linux 系统中反映 CPU 调度压力最直接的指标之一。它不等于 CPU 使用率，但对响应时间有显著影响——队列越长，新任务等待被调度的时间就越久，平均响应时间自然上升。
运行队列长度与响应时间的关联逻辑
运行队列中存放的是 处于 runnable 状态（已就绪、只等 CPU 时间片）的进程或线程。当 r 值持续高于 CPU 核心数，说明有进程在排队等待，无法立即获得 CPU 执行权：
- r ≈ 0～1：多数任务可即时调度，响应延迟低（通常毫秒级）
- r 持续 ≥ CPU 核数 × 2：开始出现明显排队，平均响应时间可能升至几十毫秒
- r 长期 > CPU 核数 × 5：调度延迟显著增加，部分请求可能超时，用户感知卡顿
如何获取并观察运行队列长度
多个命令可实时或历史查看 r 值，注意它们统计口径一致（即 /proc/loadavg 中第一个字段、vmstat 的 r 列、sar -q 的 runq-sz）：
-
vmstat 1：每秒输出，看第一列 r（如
r=8表示当前有 8 个就绪进程在排队） - sar -q 1：输出 runq-sz 字段，同时附带 1/5/15 分钟平均负载，便于对比趋势
- cat /proc/loadavg：首字段即当前瞬时运行队列长度（非平均值），适合脚本采集
结合响应时间做归因分析
单看 r 值不够，需和实际服务响应时间对齐才能确认是否构成瓶颈：
- 用 pidstat -u 1 查看高 CPU 占用进程，确认是否某业务进程持续占用 CPU 导致其他请求排队
- 用 latencytop 或 perf sched record 捕获调度延迟（sched:switch 事件），定位具体进程的等待时间分布
- 若应用层监控显示 P95 响应时间突增，同时 vmstat 中 r 值同步跳升到 6+，且 %id
常见误判与注意事项
运行队列长 ≠ 一定是 CPU 不够，也可能是其他资源阻塞引发连锁反应：
- I/O 密集型进程频繁睡眠唤醒，虽不占 CPU，但会反复进出运行队列，推高 r 值（此时 %wa 也会升高）
- 大量短生命周期进程（如 fork-bomb、高频 cron）导致频繁上下文切换，r 波动剧烈但 %us 不一定高
- NUMA 不均衡或中断集中在一个 CPU 上，造成局部队列堆积，而整体平均 r 值尚可——需用 mpstat -P ALL 1 查各核 r 值分布
