Linux怎么查看CPU上下文切换频率

一旦cs值冲到每秒1000次以上，基本就该着手排查了——这往往就是不少服务开始变得不稳定的第一个明确信号。排查时，先用vmstat 1盯住整体量级，但别只看一个数字，必须把r、b、in几个指标一起联动起来判断根因；接着再用pidstat -w 1（加-t）下钻到进程和线程层面，分别定位自愿/非自愿切换的情况，最后再结合/proc/stat里ctxt的增量，确认长期趋势到底是偶发波动，还是已经持续走高。

超过1000次/秒的cs值就该动手查了——这不是警报阈值，而是多数服务开始失稳的信号起点。

用vmstat 1看系统级总量，但别只盯cs数字

运行vmstat 1，第三行开头的cs列是每秒上下文切换总次数，但它混着进程、中断、软中断三类切换，不能直接归因到代码或配置问题。

• cs高 + r（就绪队列）远大于 CPU 核数 → CPU 资源争抢严重，优先查线程数或调度策略
• cs中等 + b（不可中断进程）> 0 → 真正卡点在 I/O 或锁，不是切换本身的问题
• 首次输出是累计值，第二秒起才是真实速率；单次峰值可能是毛刺，连续 5 秒 >1000 才值得跟进
• in（中断次数）同步飙升时，cs高大概率来自网卡、磁盘驱动等硬件中断，和应用层无关

用pidstat -w 1定位具体进程和切换类型

pidstat -w必须带采样间隔（如1），否则立即退出无输出——这是最常卡住的地方。它能拆出两类关键指标：

• cswch/s：自愿切换，进程主动让出 CPU，常见于read()/write()阻塞、锁等待、条件变量休眠
• nvcswch/s：非自愿切换，时间片被强制收回，典型如线程数远超 CPU 核数、Ja va GC 抢占、实时进程抢占
• Ja va 应用中cswch/s突增 + jstack显示大量BLOCKED → 锁竞争；nvcswch/s >50 且%CPU低 → 线程模型过载
• 加-t才能看到线程级数据（LWP），否则多线程进程的切换会被平均稀释，看不出真实热点

用grep ctxt /proc/stat验证长期趋势，避开瞬时抖动

直接读内核统计比工具更稳：grep ctxt /proc/stat返回的是系统启动以来的总切换次数，适合排除毛刺干扰。

• 隔 10 秒执行两次，差值除以 10 得到平滑 cps，比vmstat或pidstat的瞬时值更可靠
• 如果 1 小时内增长 360 万次（即平均 1000/s），而业务 QPS 没变 → 底层有隐性资源争抢，比如连接池耗尽、日志刷盘频率突增
• 注意：/proc/stat的ctxt值本身无意义，关键是看单位时间内的增量速率，不是绝对数值

容易忽略的底层细节：中断和线程模型混淆判断

vmstat的cs包含中断上下文切换，而pidstat -w只统计用户态进程——两者永远对不上，这不是工具 bug，是设计使然。

• 网卡每秒触发 5000 次软中断，vmstat照样计入cs，但pidstat完全不体现
• 进程状态为D（不可中断睡眠）时，pidstat -w不会显示该进程，哪怕它正卡在磁盘 I/O 上引发连锁唤醒
• 老版本sysstat（如 RHEL 7 自带的 10.1.5）不支持-w和-t同时生效，先跑pidstat -V确认版本 ≥ 11.0.0

真正难的不是看到cs高，而是分清这高到底是来自你的 Ja va 线程、Nginx 工作进程、还是网卡驱动——三者修复路径完全不同。别跳过r/b/in联动分析，也别绕过pidstat -t看线程级数据，否则你只是在给表象打补丁。