高负载下上下文切换过多表明cpu调度开销过大而非算力不足；需用vmstat看cs和r值判断是否异常，pidstat -w区分自愿与非自愿切换，再结合iowait、perf等工具定位i/o、锁竞争或内核路径问题。
高负载下上下文切换过多，说明 CPU 大量时间花在任务切换上，而非实际执行业务。这不是 CPU 算力不够，而是调度开销压垮了效率。关键要区分是自愿切换（等资源）还是非自愿切换（被抢走时间片），再定位到具体进程和原因。
看整体切换频率是否异常
先用 vmstat 1 每秒采样一次，重点关注 cs（context switch）列：
- 空闲系统通常 cs ；持续超过 5000/秒 就需警惕
- 同时看 r（就绪队列长度）：若 r 远大于 CPU 核数，说明大量进程在排队抢 CPU
- 再对比 in（中断次数）：如果 cs 和 in 都很高，可能是网络或硬件中断引发连锁调度
定位高切换的进程和线程
用 pidstat -w 1 查每个进程的切换明细：
- cswch/s 是自愿切换：进程主动让出 CPU，常见于等待 I/O、锁、内存分配
- nvcswch/s 是非自愿切换：时间片用完被强制切走，说明该进程在“硬刚” CPU，或有大量短生命周期线程
- 重点关注 nvcswch/s > 1000 的进程，尤其是 Java、Node.js 或多线程服务类应用
判断切换类型并追根溯源
根据切换性质选择下一步：
- 如果 cswch 高 + wa 高：进程频繁因磁盘慢、NFS 挂载失败、日志刷盘卡住而等待 → 查 iotop 和 ps aux | awk '$8 ~ /D/' 找 D 状态进程
- 如果 nvcswch 高 + us 高：用户态代码存在高频锁竞争、自旋等待、或线程池配置过小导致线程反复创建销毁 → 用 perf record -e sched:sched_switch -a sleep 10 抓调度事件，再 perf script 分析热点
- 如果 nvcswch 高 + sy 高：内核路径争用严重，比如大量 epoll_wait、futex 或文件描述符操作 → 结合 perf top -e 'syscalls:sys_enter_*' 看系统调用分布
验证与收口
改完之后不能只看 CPU 使用率降没降，要确认切换压力真正缓解：
- 再次运行 vmstat 1 5，观察 cs 是否回落到千级以下
- 用 pidstat -w 1 3 确认高 nvcswch 进程已消失或大幅下降
- 检查 uptime 中的 load average 是否同步回落，且 r 值回归正常（≤ CPU 核数）
