最可靠信号是运行队列长度（top中r值）和线程就绪状态；r值持续大于逻辑CPU核数表明线程排队等待CPU调度，结合vmstat的r、cs、us+sy及cgroup、调度策略等可精准定位调度瓶颈。

直接看运行队列长度和线程就绪状态，这是判断进程是否因缺 CPU 而排队等待的最可靠信号。

看 top 中的 r 值和线程就绪数

启动 top 后，第一行末尾的 load average 三个数值里，1 分钟值是关键；第二行开头的 r（running + runnable）值更关键——它代表当前时刻有多少线程在等待 CPU 调度。如果 r 值持续大于逻辑 CPU 核数（可用 lscpu | grep "CPU(s)" 查），说明有线程在队列里排队，不是没活干，而是没轮上。

• 例如：4 核机器，r 长期稳定在 12，意味着平均有 8 个线程在“干等”CPU
• 按 H 切换到线程视图，观察哪些线程的 STATE 是 R（运行中）或刚从 S（睡眠）变回 R 却迟迟不执行——这是调度延迟的直观表现
• 结合 WCHAN 字段（需按 f 开启），若大量线程卡在 schedule、pick_next_task 或空 WCHAN，说明正陷在调度器内部排队

用 vmstat 抓取调度压力趋势

vmstat 1 每秒输出一行，重点关注三列：

linux-sysadmin

Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...

下载

• r：同 top 的 r，但提供连续时间序列，能看清高峰是否规律（如每分钟 cron 触发后 r 突增）
• cs：每秒上下文切换次数。若 r 高且 cs 也高（比如 > 50k/s），说明调度器频繁抢夺 CPU，线程刚上 CPU 就被切走，加剧等待感
• us + sy：二者之和远低于 100% 但 r 仍高，基本可排除 CPU 计算瓶颈，锁定为“调度排队”本身的问题（比如调度策略、cgroup 限频、RT 进程抢占）

检查是否被 cgroup 或调度策略压制

即使系统整体不忙，单个进程也可能因资源限制被迫等待：

• 查该进程所属 cgroup：cat /proc/[PID]/cgroup，再看对应 cpu.max 或 cpu.weight 设置（路径如 /sys/fs/cgroup/cpu/xxx/）
• 看进程调度策略：chrt -p [PID]。若为 SCHED_FIFO 或 SCHED_RR，可能长期霸占 CPU；若为 SCHED_BATCH 或被 renice 调低优先级，就容易排在队尾
• 检查是否有其他高实时优先级任务（ps -eo pid,tid,class,rtprio,ni,comm | grep -E "(FF|RR)"），它们会挤占普通进程的调度机会

确认是否真的“等 CPU”，而非误判

调度延迟 ≠ 所有延迟。务必先排除常见干扰项：

• 如果 wa（iowait）高，进程实际在等磁盘，不是等 CPU；此时 r 高是结果，不是原因
• 如果大量进程处于 D 状态（不可中断睡眠），它们计入 load 但不进运行队列，不会拉高 r 值，也不会造成调度延迟
• 用 perf sched record -a sleep 10 && perf sched latency 可直接统计各进程的“唤醒到运行”延迟（即真实调度延时），比间接指标更准