直接看 vmstat 的 cs 字段可判断是否过度调度，关键看 cs 与 in 的比值：cs > 5×in 或 cs 持续 > 50,000/秒需排查；结合 r > cpu核数、sy > 25% 且 cs 同高，可确认调度过载；使用 vmstat 1 -s m 连续观察趋势，避免依赖瞬时值或平均值。
重点关注 cs 和 in 的比值关系
上下文切换（cs）本身是正常行为，但若 cs 远高于 in（中断次数），说明内核调度频繁介入，而非由硬件事件驱动，大概率存在过度调度。
- 空闲系统典型值：cs 25–40 /秒，in 15–25 /秒 → cs ≈ in，属健康状态
- 警戒线参考：cs > 5×in 或 cs 持续 > 50,000/秒（视CPU核数而定），需深入排查
- 例如：cs=86,000，in=1,200 → 中断极少但切换爆炸，基本可判定为进程/线程竞争激烈
同步观察 r 和 sy 指标定位根源
`r`（就绪队列长度）和 `sy`（内核态CPU占比）能帮你确认是不是调度器“忙不过来”了。
- r 值持续大于逻辑CPU核数（如 4 核机器 r ≥ 5）→ 就绪任务堆积，调度压力大
- sy > 25% 且伴随高 cs → 内核花太多时间做上下文保存/恢复，不是在干活
- 注意区分：sy 高 + cs 不高 → 可能是系统调用密集（如大量 read/write）；sy 高 + cs 也高 → 典型调度过载
用 vmstat -S 看清单位避免误读
`-S` 参数指定内存单位（如 `-S M` 显示 MB），但它对 `cs`、`in` 等计数字段无影响——这些始终是“每秒次数”，无需换算。但加 `-S` 能让内存列更易读，间接提升整体监控效率。
- 正确用法：
vmstat 1 -S M（每秒刷新，内存以 MB 显示） - 错误理解：“vmstat -S”能改变上下文切换的统计方式 → 实际上它只影响内存列单位
- 建议固定使用：
vmstat 1 -S M，兼顾可读性与实时性
单次快照不如连续观察趋势
瞬时值容易受噪声干扰，真正有价值的信号藏在变化节奏里。
- 运行
vmstat 1 -S M至少 30 秒，观察 cs 是否呈脉冲式飙升（如周期性跳到 10w+ 后回落） - 对比负载变化：启动某个服务后 cs 是否陡增？停止后是否回落？这是最直接的因果证据
- 避免只看平均值：平均 cs=2000 可能掩盖了某几秒 cs=80000 的尖峰，这类尖峰才是性能卡顿的元凶
