sar -q 是观察系统 CPU 调度压力最直接的手段，聚焦就绪队列长度而非 CPU 使用率；关键字段包括 runq-sz（就绪进程数）、plist-sz（总进程线程数）、ldavg-1/5/15（系统平均负载）、blocked（阻塞进程数），需结合 sar -u 交叉验证，典型饱和表现为 runq-sz ≥ CPU 核心数 × 2 且 %user + %system > 90%、%idle 极低。
sar -q 是观察系统 CPU 调度压力最直接的手段之一，它不看 CPU 使用率百分比，而是聚焦“有多少进程在排队等 CPU”——这才是判断调度是否饱和的核心依据。
理解 -q 输出的关键字段含义
运行 sar -q（默认每10秒一次，共输出1次）后，你会看到类似这样的列：
- runq-sz：当前就绪队列中的进程数（即已准备好运行、只等 CPU 时间片的进程）。该值 > CPU 核心数 × 3 是明显过载信号
- plist-sz：内核进程列表中所有进程+线程总数，反映整体负载规模，但不直接指示调度瓶颈
- ldavg-1 / ldavg-5 / ldavg-15：分别表示过去1/5/15分钟的平均负载值。注意：这是“系统级负载”，不是单核利用率；若为16核机器，ldavg-1 = 16 表示平均每个核恰好满负荷
- blocked：当前处于不可中断睡眠状态（如等待磁盘 I/O）的进程数。该值持续升高往往预示 I/O 成为瓶颈，间接加重调度队列压力
结合 CPU 使用率交叉验证调度饱和度
仅看 runq-sz 容易误判。例如队列长度高但 %idle 也高，说明可能是短时突发或采样抖动；而 runq-sz 高 + %iowait 高，则大概率是 I/O 等待拖慢了进程释放 CPU，造成虚假排队。
- 推荐组合命令：
sar -q 2 5 && sar -u 2 5，同步观察队列与 CPU 态分布 - 典型饱和特征：
runq-sz ≥ CPU核心数 × 2且%user + %system > 90%，同时%idle - 若
runq-sz持续高于核心数但%idle仍有 10%+，需检查是否因锁竞争、内存缺页或上下文切换（sar -w）导致进程频繁进出队列
用历史数据定位间歇性饱和问题
sar 默认每天生成二进制日志（如 /var/log/sa/sa09），可回溯任意时段的队列状态：
- 查今天凌晨2–4点的队列峰值：
sar -q -f /var/log/sa/sa09 -s 02:00:00 -e 04:00:00 | awk '{print $2}' | sort -n | tail -1 - 对比负载与 CPU 使用趋势：
sar -q -f /var/log/sa/sa09 -s 14:00:00 | head -20和sar -u -f /var/log/sa/sa09 -s 14:00:00 | head -20并排查看 - 注意：sa 日志是二进制格式，必须用
sar -f读取，不能直接 cat 或 grep
多核系统下避免“平均掩盖热点”
sar -q 只报告全局队列，无法体现单核过载。当整体 runq-sz 不高但用户感知卡顿时，应补查 CPU 分核情况：
- 运行
sar -P ALL -q 1 3（需搭配 -P 才能触发 per-CPU 队列？实际不支持；-q 本身无 -P 选项，故需换思路）→ 正确做法是：用sar -P ALL 1 3查各核 %user/%system，并结合runq-sz判断是否存在负载不均 - 若某核 %user 接近100% 而其他核空闲，即使总 runq-sz 低，该核的局部队列已实质饱和
- 此时应检查进程绑定（taskset）、中断亲和性（/proc/irq/*/smp_affinity）或应用线程模型
