空闲系统cs通常10–100次/秒，持续超5万/秒需警觉，20万/秒以上基本判定为上下文切换吃CPU；关键要结合r列判断，如8核机r长期>16且cs>30万，说明非自愿切换爆炸。
vmstat 的 cs 值多少算异常
看 vmstat 1 输出里的 cs 列，不是绝对值说了算，得结合系统负载和 CPU 核数判断。空闲系统通常 cs 在 10–100 次/秒；持续超过 5 万/秒就要警觉；上到 20 万/秒以上，基本可以断定是上下文切换在吃 CPU。但关键要看 r（就绪队列长度）是否远大于逻辑 CPU 核数——比如 8 核机器，r 长期 >16，同时 cs >30 万，说明大量进程在排队抢 CPU，强制调度频繁，非自愿切换爆炸。
pidstat -w 怎么区分自愿和非自愿切换
pidstat -w 1 输出里有两列必须盯紧：cswch/s 是自愿切换，nvcswch/s 是非自愿切换。它们背后的问题完全不同：
-
cswch/s高：进程自己让出 CPU，常见于等锁、等 I/O、等信号量——比如数据库连接池耗尽、Redis 线程阻塞在epoll_wait、Java 应用大量线程卡在synchronized上 -
nvcswch/s高：CPU 时间片被硬生生掐断，典型是线程太多、单核跑几十上百个活跃线程，调度器被迫高频切人——比如用sysbench --threads=128压测时，nvcswch/s动辄破万
如果一个进程 nvcswch/s 远高于 cswch/s，优先查它是不是线程数失控；反之，cswch/s 主导，就得顺着它的系统调用链往下挖，比如用 strace -p <pid></pid> 看它卡在哪。
sy% 高但 us% 低，为什么 top 不显示高 CPU 进程
这是最典型的“CPU 显得空闲但系统卡死”的场景。top 里 %Cpu(s) 行的 sy（系统态）占比很高，比如 70%+，而 us（用户态）只有 10%，且所有进程的 CPU% 加起来不到 30%——这说明 CPU 大量时间花在内核调度、中断处理、上下文切换本身，而不是执行你的代码。这时候 vmstat 的 cs 和 in（中断）往往同步飙升。别再盯着 top 排名前几的进程了，它们可能只是“受害者”，真凶是内核调度压力本身，比如网卡软中断风暴、定时器轮询过密、或某个驱动反复触发高频率中断。
怎么快速定位是哪个线程在疯狂切换
用 pidstat -wt 1（注意 -t 参数），它会把每个线程单独列出来，输出带 TID 的 cswch/s 和 nvcswch/s。重点关注那些 nvcswch/s 单独就上万的线程。拿到 TID 后，用 ps -T -p <pid></pid> 查它属于哪个进程、名字是什么；再用 cat /proc/<pid>/stack</pid> 看内核栈——如果栈顶反复出现 __schedule、pick_next_task_fair 或 do_wait，基本坐实是调度器在反复抢救这个线程。这种线程往往没有有意义的业务堆栈，只在内核里打转，删掉它或限制其并发数，常能立竿见影降 cs。
cs，而是分清它是症状还是病因——有时候它只是结果，比如磁盘卡住导致大量进程进 D 状态，等恢复时一哄而上抢 CPU，瞬间推高 cs；有时候它就是根因，比如一个 bug 导致线程死循环调用 nanosleep(1)，每毫秒主动让出一次，cswch/s 直接飙到 1000+。得先看 cswch 和 nvcswch 谁主导，再决定往应用层还是内核层深挖。 
