sar -q 是评估 CPU 调度饱和度最直接有效的方式，聚焦运行队列长度（runq-sz）、平均负载（ldavg-1）和阻塞进程数（blocked），需结合 CPU 核数归一化判断是否饱和，而非仅看负载绝对值。
sar -q 是评估 CPU 调度饱和度最直接有效的方式之一，它不看 CPU 使用率百分比，而是聚焦于“有多少进程在排队等 CPU”——这才是判断调度是否饱和的核心依据。
理解 -q 输出的关键字段含义
运行 sar -q（默认每10秒一次，共1次）会输出类似：
10:02:01 AM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 blocked
10:02:11 AM 2.3 342 1.87 1.62 1.51 0
重点关注三项：
- runq-sz：运行队列长度，即平均有多少进程/线程正等待获得 CPU 时间片（非运行中，而是就绪态但没轮到）
- ldavg-1：过去1分钟的系统平均负载（load average），数值等于所有 CPU 核心上 runq-sz 的总和（含等待 I/O 的不可中断进程）
- blocked：当前被阻塞在不可中断睡眠状态（如等待磁盘 I/O）的进程数；若该值持续偏高，说明瓶颈可能在 I/O，而非 CPU 调度本身
判断 CPU 调度是否饱和的标准
关键不是看绝对负载值，而是结合 CPU 核心数做归一化分析：
- 单核系统：runq-sz 长期 > 1 表示调度排队，存在饱和倾向；> 3 则明显过载
- 多核系统（如 16 核）：理想情况下，平均每个核的 runq-sz 应 ≤ 1。可粗略用 runq-sz / CPU 总核数 估算每核排队压力。例如 runq-sz = 12，16 核 → 每核约 0.75，尚可接受；若 runq-sz = 28 → 每核 1.75，已出现排队积压
- 注意 ldavg-1 与 runq-sz 的差异：ldavg-1 包含了不可中断进程（如 I/O 等待），而 runq-sz 只统计真正就绪、只等 CPU 的进程。若 ldavg-1 显著高于 runq-sz（比如 3.2 vs 0.8），且 blocked 值高，说明问题不在 CPU，而在 I/O 或锁竞争
实战监控建议
避免只看单次快照，应结合时间维度和采样策略：
- 短时诊断：用
sar -q 1 10每秒采样10次，观察 runq-sz 波动范围。突发性尖峰（如从 0.5 冲到 8.0）提示瞬时调度压力大 - 历史回溯：配合系统默认收集的日志，查当天数据用
sar -q -f /var/log/sa/sa$(date +%d)；查前天用sa$(date -d '2 days ago' +%d) - 关联验证：当 runq-sz 持续偏高时，立刻补查
sar -u 1 5和sar -P ALL 1 5，确认是整体 CPU 满载，还是某几个核心过热导致负载不均
常见误判提醒
别把高 load average 当成 CPU 忙碌：
- 一个 CPU 密集型进程占满单核，%user=100%，runq-sz≈0，ldavg-1≈1 —— 这是“忙”，但不“堵”
- 多个进程频繁等待磁盘，%iowait 高、%idle 也高，但 runq-sz 小、blocked 大、ldavg-1 却很高 —— 这是“I/O 堵”，不是 CPU 调度饱和
- runq-sz 稳定在 0.3，但响应延迟高 —— 可能是上下文切换过多（用
sar -w查 %cswch）、或内存不足引发频繁换页（sar -B）
