直接运行vmstat 1即可实时监控cs（上下文切换）和in（中断次数），需同步观察r、b列联动：r超cpu核数表cpu过载，b升高表i/o阻塞，in与cs同步飙升表中断风暴。

直接运行 vmstat 1 就能动态监控上下文切换（cs）和中断次数（in），不需要额外安装、不依赖 root 权限，几乎所有 Linux 发行版都预装了这个命令。

看对位置：cs 和 in 在 system 模块最右侧

执行 vmstat 1 后，输出中第三行标为 -system-- 的部分包含两个关键字段：

• cs：每秒上下文切换次数（不是瞬时值，是本次 1 秒采样周期内的平均速率）
• in：每秒硬件中断次数（来自网卡、磁盘、定时器等设备）

注意：这两列单位固定为「次/秒」，加 -S M 或 -S K 只影响内存列（free/buff/cache）的显示单位，对 cs/in 完全无影响，不必换算。

宝塔Linux面板11.8.1

宝塔Linux面板11.8.1为官网当前正式版，新增AI建站能力并经过宝塔网站工程师深度调教，开放自定义AI功能API，同时对WAF进行界面重构和深度优化，提升拦截能力与运维效率。

下载

别只盯数字，重点看四列联动关系

单看 cs=8000 没意义，必须同步观察 r、b、in 才能判断根因：

• r > CPU 核数（如 4 核机器 r ≥ 5）且 cs 高 → CPU 竞争激烈，大量非自愿切换
• b > 0 且 cs 中等偏高 → 进程卡在不可中断睡眠（如磁盘 I/O、锁等待），频繁挂起/唤醒，自愿切换为主
• in 与 cs 同步飙升（比如都从 300 跳到 9000）→ 中断风暴，常见于网卡软中断、NVMe 驱动异常或定时器过载
• cs 高但 us/sy 都低 → 切换不是因计算忙，而是进程在等资源（锁、网络响应、磁盘读写），此时 %wa、bi/bo 往往也升高

用对节奏：连续观察比单次快照更可靠

刚开机时 cs 短暂冲到 5k–8k 属正常（systemd 启服务、日志刷盘），真正要关注的是持续性和模式：

• 至少运行 vmstat 1 30 秒以上，观察是否出现脉冲式尖峰（如周期性跳到 20k+ 后回落）
• 对比操作前后变化：启动某服务后 cs 是否陡增？停止后是否回落？这是最直接的因果证据
• 避免用 vmstat 5 这类长间隔——短时切换风暴（如定时任务批量 fork）容易被漏掉

知道它能做什么，也得知道它不能做什么

vmstat 是第一道筛子，不是终点：

• 它统计的是内核全局视角的总切换数，含进程切换 + 硬件中断 + 软中断三类开销
• 所以 vmstat cs 一定 ≥ 所有进程 pidstat -w 输出的 cswch/s + nvcswch/s 总和
• 想定位“谁在切”“为什么切”，必须配合 pidstat -w 1（看每个进程的自愿/非自愿切换）或 perf record -e context-switches