vmstat 的 cs 值需结合 r、us、sy、b 等指标综合判断：r 持续大于 CPU 核数且 cs > 5000 表明调度竞争；cs 高但 us/sy 低说明资源等待；b > 0 且 cs 中等指向 I/O 卡顿；瞬时跳变需连续观察。
vmstat 的 cs 值怎么看才不算误判
单看 cs 数字本身毫无意义，它只是系统级总量，包含进程切换、中断上下文、软中断上下文三类。比如 cs=12000，可能是网卡每秒触发 8000 次 NET_RX 软中断（查 /proc/softirqs），剩下才是用户进程行为。
关键判断点：
-
r（就绪进程数）持续 > CPU 核心数，且cs同步 > 5000 → CPU 调度竞争真实存在 -
cs高但us（用户态 CPU）和sy（内核态 CPU）都低 → 切换不是因为计算忙，而是大量进程在等资源（锁、磁盘、网络） -
b（不可中断睡眠进程）> 0 且cs中等 → 真凶是 I/O 卡顿，上下文切换只是副产品 - 刚运行
vmstat 1时cs突然跳到 6000+ → 很可能是 systemd 启服务或日志刷盘的瞬时毛刺，连续观察 10 秒再下结论
pidstat -w 输出里 cswch/s 和 nvcswch/s 怎么区分根因
cswch/s（自愿切换）高，说明进程自己主动让出 CPU；nvcswch/s（非自愿切换）高，说明被调度器强行打断。二者开销不同，排查路径完全不同。
常见对应关系：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
cswch/s高 +bi/bo（I/O）也高 → 锁定为磁盘 I/O 瓶颈，比如数据库慢查询、日志同步刷盘 -
cswch/s高 +%CPU低 + Java 进程jstack显示大量BLOCKED→ 锁竞争激烈，不是 CPU 不够 -
nvcswch/s高 +r> CPU 核数 +us+sy都高 → 线程数远超 CPU 核心，或有 rogue 实时进程（用ps -eo pid,cls,rtprio,ni --sort=-rtprio查） -
nvcswch/s高 +%CPU低 + Java GC 日志频繁 → GC 导致 safepoint 抢占，线程反复挂起
为什么 pidstat -w 必须带采样间隔才能生效
pidstat -w 不加时间参数会立刻退出、无输出——这是新手最常卡住的地方。它默认只输出一次累计值，而你需要的是速率（/s），必须靠两次采样做差分计算。
实操要点：
-
pidstat -w 1：每秒刷新，只显示cswch/s或nvcswch/s非零的活跃进程，适合日常巡检 -
pidstat -w -p 1234 0.5：盯住某个 PID，半秒一采，能抓到 GC 触发瞬间这类短时抖动 -
pidstat -w -t -p 1234 1：开启线程级统计（LWP），Java/Python 多线程场景必须加-t，否则进程级数值会被平均稀释 - 注意：
pidstat首次输出是累计值，第二次才开始算增量速率；老版本 sysstat（如 RHEL 7 自带的 10.1.5）不支持-w和-t同时生效，先跑pidstat -V确认版本 ≥ 11.0.0
真正难的不是查出谁在切，而是判断它该不该切
一个 nginx worker 进程 cswch/s=300 是正常的——它在 epoll_wait 上等待连接，属于高效等待；但同样数值出现在一个计算密集型 Python 进程上，就说明它频繁被 I/O 或锁打断。
容易被忽略的细节：
- 进程状态为
D（不可中断睡眠）时，pidstat -w完全不显示它——此时要用ps -o pid,comm,state,wchan -p PID查卡在哪条内核路径上 -
grep ctxt /proc/stat给出的是系统启动以来总次数，适合排除瞬时毛刺：隔 10 秒查两次，差值除以 10 才是真实 cps，比实时工具更平滑 -
perf record -e sched:sched_switch -a sleep 10能抓到具体哪两个线程在切、切之前在哪个函数阻塞——但代价是性能开销大，别在生产环境长期开着
