cs持续超10k/s需警惕，表明系统被调度开销拖垮；应结合r、us、sy等列判断根因，并用pidstat -w定位具体进程。
直接看 cs 列，数值持续高于 10k/秒就要警惕——这不是“高”，是系统正在被调度开销拖垮。
vmstat 的 cs 列怎么看才不误判
运行 vmstat 1 后，输出最右端的 system 模块里有一列叫 cs，它代表「每秒上下文切换次数」。注意：这是自上次采样以来的平均值，不是瞬时峰值。
- 刚启动时
cs偶尔跳到 5k–8k 属正常（比如 systemd 启动服务、日志刷盘） - 若连续 5 秒以上稳定在 10k+，且伴随
r（就绪进程数）> CPU 核心数，大概率是 CPU 调度瓶颈 -
cs高但us（用户态 CPU）和sy（内核态 CPU）都低？说明切换不是因计算密集，而是大量进程在等资源（如锁、磁盘、网络） - 别只盯单次输出——用
vmstat 1 10看 10 次趋势，比看一次cs=12456有用得多
为什么 vmstat 只能看总量，不能定位谁干的
vmstat 读的是 /proc/stat 中的 ctxt 字段，它只统计系统级总次数，不区分进程、线程或切换类型。
- 你看到
cs=25000，但不知道是 10 个 Java 进程各切 2500 次，还是 1 个死循环线程切了 24990 次 - 它不告诉你哪些是自愿切换（
cswch/s，等 I/O）、哪些是非自愿（nvcswch/s，被抢时间片），而这二者根因完全不同 - 想定位具体进程？必须上
pidstat -w 1，它从/proc/[pid]/stat抓每个进程的voluntary_ctxt_switches和nonvoluntary_ctxt_switches
vmstat 的常见误读和陷阱
很多人把 vmstat 当成“万能体检表”，结果被几个字段带偏：
-
r长期 > CPU 核心数，不代表 CPU 不够——可能是大量进程卡在不可中断睡眠（b列高），这时cs反而不高，真凶是磁盘或 NFS -
cs看似不高，但in（每秒中断数）飙到 50k+？说明硬件中断频繁（比如网卡软中断），这也会引发大量上下文切换，但vmstat不体现中断上下文切换细节 - 用
vmstat 5间隔太长，会漏掉短时脉冲型切换风暴（如定时任务批量 fork）；建议先用1秒粒度捕获异常，再拉长观察 -
vmstat默认单位是 KB，但cs是纯计数，不受-S参数影响——这点文档很少提，容易以为加了-S M会让cs变“兆级”
真正难的不是查出 cs 高，而是区分它是症状还是病因。比如一个 Java 应用 nvcswch/s 爆表，十有八九是 GC 频繁导致线程反复被抢占；而 cswch/s 高却 bi/bo 也高，基本可以锁死是磁盘 I/O 卡住线程。这些判断链条，vmstat 自己给不了，得靠它和 pidstat、iostat 搭配着看。
