直接用 vmstat 1 实时观察 cs、in、r、b 四列联动：cs 高且 in 同步飙升为中断风暴，r 超 CPU 核数为 CPU 过载，b 升高则多为 I/O 阻塞；仅看 cs 数值易误判，因其包含中断和软中断开销。
直接用 vmstat 1 就能实时看中断（in）和上下文切换（cs）的动态变化，-N 参数在主流 Linux 发行版（如 RHEL、Ubuntu、CentOS）的 vmstat 中并不存在——它不是标准选项，加了会报错或被忽略。真正有效的命令就是 vmstat 1，每秒刷新一次，足够捕捉分布规律。
重点关注这四列联动关系
单看 cs 或 in 数值意义不大，必须同时观察以下四列才能识别模式：
- cs：每秒上下文切换总数。空闲系统通常 ≤1500；持续 ≥5000 需警惕
- in：每秒中断次数。与 cs 同步飙升（比如两者都从 200 跳到 8000），大概率是网卡、磁盘或定时器引发的中断风暴
- r：就绪队列长度。若 r 长期大于 CPU 核数（如 8 核机器 r=12），说明 CPU 竞争激烈，cs 高主要来自非自愿切换
- b：不可中断睡眠进程数。b > 0 且伴随 cs 上升，常见于 I/O 延迟、锁争用或 NFS 卡顿
典型分布规律识别示例
运行 vmstat 1 观察几轮输出，注意数值走向：
- CPU 过载型：r=9, b=0, in=300, cs=11000 → r 超核数 + cs 高 + in 正常 → 多进程争抢 CPU，调度器频繁抢占
- I/O 阻塞型：r=2, b=6, in=400, cs=8500 → b 明显升高 + cs 高 → 进程反复挂起/唤醒，自愿切换主导
-
中断风暴型：r=1, b=0, in=12000, cs=12500 → in 与 cs 几乎等幅上涨 → 检查
/proc/interrupts，定位高发中断源（如 eth0、nvme）
确认中断来源的补充操作
vmstat 只提示“可能有中断问题”，要定位具体设备，需配合：
- 执行
watch -n 1 'grep -E "^(eth|nvme|ata|timer)" /proc/interrupts'，观察各设备中断计数每秒增量 - 对比两次快照：
cat /proc/interrupts | awk '{print $1,$NF}'，间隔 5 秒再执行一次，算差值 - 若 timer（LOC）每秒约 1000 次属正常；但 eth0 从 5000/s 突增至 30000/s，则极可能是网络包洪泛或驱动异常
为什么不能只依赖 cs 数值做判断
cs 是内核统计的全局事件总和，含三类开销：
- 进程/线程切换（用户任务间）
- 硬件中断处理时的上下文保存/恢复
- 软中断（如网络协议栈、ksoftirqd）引发的切换
所以 cs 高 ≠ 一定是应用层问题。例如 cs=6000 且 in=5800，那其中 5800 次根本和进程无关，而是中断处理本身带来的代价。
