vmstat 1可直接查看cs值，无需安装或root权限；cs为每秒上下文切换次数，空闲系统通常1000–1500/s，持续≥5000/s需警惕，须结合r、b、in联动分析根因。

直接运行 vmstat 1 就能看到 cs 值

不用装包、不需 root 权限，vmstat 是绝大多数 Linux 发行版预装的工具。执行 vmstat 1 后，输出中第三行（system 模块）最右侧的 cs 列就是「每秒上下文切换次数」——它不是瞬时值，而是本次采样周期内（1 秒）的平均速率。

常见误区：vmstat -S M 或 vmstat -S K 只影响内存列单位（如 free、buff），对 cs、in 等计数字段完全无影响。它们始终是「次/秒」，无需换算。

• 刚启动时 cs 短暂跳到 5k–8k 属正常（比如 systemd 拉起服务、日志刷盘）
• 空闲系统典型值：1000–1500 /秒；持续 ≥5000 /秒需警惕
• 别只看单次输出——至少观察 10 秒以上，重点识别是否脉冲式飙升（如周期性冲到 20k+ 后回落）

cs 高但不知道根因？必须联动看 r、b、in

单独一个 cs=12000 几乎没用，真正要盯的是这四列的组合关系：

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

为什么 vmstat 的 cs 和 pidstat -w 加起来对不上

因为 vmstat 统计的是内核全局视角的上下文切换总数，包含三类开销：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 进程/线程级切换（用户态任务间）
• 硬件中断处理时的上下文保存/恢复（比如网卡收包触发的 eth0 中断）
• 软中断上下文切换（如 ksoftirqd 处理网络协议栈、定时器）

而 pidstat -w 只抓每个进程的 cswch/s（自愿）和 nvcswch/s（非自愿），不统计中断相关部分。所以 vmstat cs 一定 ≥ 所有进程 cswch/s + nvcswch/s 总和——这不是 bug，是设计如此。

例如：cs=6000 且 in=5800，那其中约 5800 次根本和你的应用进程无关，纯属中断处理代价。

别被 cs 数值带偏，真问题往往藏在 pidstat -w 里

vmstat 只负责告诉你“有没有问题”，定位“谁干的”和“为什么切”必须切到 pidstat -w：

• 首次运行 pidstat -w 1 输出的是累计值，第二次才开始算增量速率，务必连续看两轮以上
• cswch/s 高 + nvcswch/s ≈ 0 → 进程主动让出 CPU，查 strace -p PID -e trace=epoll_wait,read,futex 看卡在哪类系统调用
• nvcswch/s 高 → 调度器强制抢占，优先检查是否有 rogue 实时进程（ps -eo pid,cls,rtprio,ni --sort=-rtprio）、Java GC 频繁或线程数远超 CPU 核数
• 进程状态为 D（不可中断睡眠）时，pidstat -w 完全不显示它——此时要用 ps -o pid,comm,state,wchan -p PID 查卡在哪个内核函数

真正难的不是看到 cs 高，而是分清它是症状还是病因；vmstat 是筛子，pidstat 才是手术刀。