vmstat 1 的 cs 列反映每秒上下文切换总数，空闲系统通常为1000–1500次/秒，持续超5000次/秒需警惕；但必须联动r（就绪队列）、b（阻塞进程）、in（中断次数）三列判断根因：r长期大于CPU核数指向CPU竞争引发非自愿切换，b升高多因I/O或锁等待导致自愿切换，in与cs同步飙升提示中断风暴。
直接用 vmstat 1 就能快速看到系统级上下文切换总量，关键不是只盯 cs 这一列，而是把它和 r、b、in 联动起来看——这样才能判断高切换是 CPU 抢不过来、I/O 卡住了，还是中断在狂轰滥炸。
怎么看 cs 列是否真的异常
空闲系统下 cs 通常在 1000–1500 次/秒；持续超过 5000 次/秒就要警觉。但不能单凭绝对值下结论：
- 对比业务基线：比如压测前是 2000/s，压测后跳到 8000/s，翻了 4 倍，这就是明确信号
- 注意单位是“每秒”，不是累计值——
vmstat 1每秒刷新一次，数值是该秒内发生的切换次数 -
cs包含进程切换 + 中断上下文切换，所以它一定大于或等于所有进程cswch + nvcswch的总和
必须联动的三列：r、b、in
cs 高只是表象，根因藏在这三列里：
-
r（就绪队列长度）：如果长期 > CPU 核数（比如 4 核机器上
r ≥ 5），说明任务排队等 CPU，驱动大量非自愿切换 - b（不可中断睡眠进程数）：升高往往对应磁盘 I/O 延迟或锁争用，进程反复挂起/唤醒，推高自愿切换
-
in（每秒中断次数）：若
in和cs同步飙升（如都从 300 跳到 6 万），大概率是网卡、NVMe 或驱动问题引发中断风暴
结合 CPU 使用率一起读
us（用户态）、sy（内核态）、id（空闲）、wa（iowait）这几列要和 cs 对着看：
-
sy显著偏高（比如 >60%）+cs高 → 内核工作过载，可能是系统调用太频繁、锁竞争激烈或软中断处理重 -
wa高 +b高 +cs高 → 不是 CPU 真忙，而是进程在等 I/O，唤醒后立刻又堵住，形成“切进来→等→切走”循环 -
id很高但r也大 → 可能是调度器异常，或者某些进程处于uninterruptible状态卡死，需查ps aux | grep 'D'
下一步该做什么
vmstat 是第一道筛子，它告诉你“是不是高”和“往哪查”，但不负责定位具体进程：
- 确认
cs异常后，立刻跑pidstat -w 1查哪个进程cswch/s或nvcswch/s突出 - 如果怀疑中断问题，用
watch -d cat /proc/interrupts看哪个 CPU 上哪个中断号涨得最快 - 想深挖函数级热点，再上
perf record -e context-switches -a sleep 10，然后perf report
