首页 > 操作系统 >Linux怎么使用vmstat查看系统上下文切换

Linux怎么使用vmstat查看系统上下文切换

来源：互联网 2026-06-24 22:58:06

vmstat的cs列显示每秒上下文切换次数，需观察10秒以上并结合r、b、in列分析。高cs可能源于CPU竞争、中断风暴或I/O等待。vmstat的cs包含中断切换，大于pidstat统计的进程切换。定位根因需使用pidstat等工具进一步诊断。

运维排查系统卡顿时，许多人习惯先查看 CPU 使用率。然而，有经验的工程师知道，上下文切换的频率往往更能暴露问题根源。而查看这个指标的最佳工具莫过于 vmstat——它几乎无需任何准备，一条命令即可呈现关键数据。

长期稳定更新的攒劲资源： >>>点此立即查看<<<

直接运行 `vmstat 1` 就能看到 cs 值

无需安装、无需 root 权限，vmstat 是绝大多数 Linux 发行版预装的工具。执行 vmstat 1 后，输出中第三行（system 模块）最右侧的 cs 列即为「每秒上下文切换次数」——它不是瞬时值，而是本次采样周期（1 秒）内的平均速率。

常见误区：vmstat -S M 或 vmstat -S K 并不会改变 cs 的单位，这两个参数仅影响内存列（如 free、buff），对 cs、in 等计数字段完全无效。cs 始终以「次/秒」为单位，无需额外换算。

单独看到 cs=12000 几乎无法说明问题，真正有价值的是以下四列的组合关系，它能直接指明切换的“性质”：

r > CPU 核数（如 4 核机器上 r ≥ 5）且 cs 很高 → 表明 CPU 竞争激烈，大量为非自愿切换（nvcswch/s 主导），进程被调度器强制占让。
b > 0 且 cs 中等偏高 → 进程陷入不可中断睡眠（常见于磁盘 I/O、锁等待），频繁挂起/唤醒，此时自愿切换（cswch/s）为主。
in 与 cs 同步飙升（例如从 300 跳至 9000）→ 这是典型的中断风暴，可能由网卡软中断、定时器或 NVMe 驱动异常引起。
cs 高但 us 和 sy 都低 → 切换并非源于计算密集，而是进程在等待资源（锁、网络、磁盘），此时 %wa 或 bi/bo 往往也居高。

这个问题几乎每位深入性能分析的人都会遇到。原因在于：vmstat 统计的是内核全局视角的上下文切换总数，它涵盖三类开销：

而 pidstat -w 仅抓取每个进程的 cswch/s（自愿）和 nvcswch/s（非自愿），完全不统计中断相关部分。因此 vmstat cs 一定 ≥ 所有进程 cswch/s + nvcswch/s 的总和——这不是 bug，而是设计使然，理解这一点后就不会再困惑。

举例说明：若 cs=6000 且 in=5800，则其中约 5800 次与应用进程无关，纯粹是中断处理付出的代价。

vmstat 的作用类似体检报告中的血常规——它提示“有异常”，但若要定位“谁干的”以及“为什么切”，必须借助 pidstat -w 这把手术刀：

首次运行 pidstat -w 1 输出的为累计值，第二次才开始计算增量速率，因此务必连续观察两轮以上，否则第一行数据会误导判断。
cswch/s 高 + nvcswch/s ≈ 0 → 进程主动让出 CPU，此时使用 strace -p PID -e trace=epoll_wait,read,futex 查明其卡在哪些系统调用上。
nvcswch/s 高 → 调度器强制抢占，优先检查是否存在 rogue 实时进程（通过 ps -eo pid,cls,rtprio,ni --sort=-rtprio 扫描），或 Java GC 频繁、线程数远超 CPU 核数。
进程状态为 D（不可中断睡眠）时，pidstat -w 完全不显示该进程——此时需用 ps -o pid,comm,state,wchan -p PID 查明它卡在哪个内核函数中。