r值长期大于CPU核数但top无高CPU进程，说明进程频繁阻塞或短时运行后让出CPU；r高+us/sy低+wa高指向I/O阻塞；r高+cs异常高反映上下文切换风暴；r高+si/so非零+free偏低表明内存压力导致换页。
vmstat 中 r 值长期大于 CPU 核数，但 top 看不到高 CPU 进程？这很典型
这种情况说明系统确实有大量进程在“排队等 CPU”，但它们并未持续占用 CPU 时间片——不是因为不忙，而是因为频繁被阻塞、切换或短暂运行后让出 CPU。单纯看 top 的 %CPU 排序会漏掉这类短生命周期、高并发、I/O 密集或调度密集型任务。
r 高 + us/sy 低 + wa 高：I/O 阻塞是主因
当 vmstat 的 r 持续 > CPU 核数，而 us 和 sy 合计远低于 70%，wa 却明显偏高（比如 >20%），基本可锁定为 I/O 等待导致的就绪队列堆积：
- 进程发起读写请求后立刻进入不可中断睡眠（b 列也会同步升高），等待磁盘/网络响应，完成后才重新进入就绪队列（r）；
- top 默认按 %CPU 排序，这些进程大部分时间在 sleep，%CPU 极低，所以“隐身”了；
- 此时应立刻执行 iostat -x 2，重点关注 await（平均等待毫秒）、%util 和 avgqu-sz：await 持续 >10ms（SATA）或 >1ms（SSD），且 avgqu-sz > 2，就是磁盘响应慢或队列过深的明确信号。
r 高 + cs 异常高 + us/sy 尚可：上下文切换风暴
如果 cs（每秒上下文切换数）远高于正常水平（例如 >5000/s，尤其对比 in 中断数），而 r 高、us/sy 却未饱和，说明 CPU 大量时间花在调度上，而非执行：
- 常见于大量短连接服务（如高并发 http API、udp 小包收发）、线程数配置过高的 java 应用、或滥用 select/poll 的程序；
- 每个请求触发一次 accept → read → write → close，伴随频繁的用户/内核态切换和线程唤醒/挂起；
- 用 pidstat -w 1 可定位具体哪个进程的 cswch/s（每秒切换次数）异常突出；优化方向包括：改用 epoll/io_uring、合并小请求、限制线程池大小、升级内核减少调度开销。
r 高 + si/so 非零 + free 明显偏低：内存压力引发连锁反应
若 swpd 不为 0，且 si 或 so 持续有值（哪怕只有几 KB/s），同时 free 内存远低于物理总量（如
- 进程缺页时需从 swap 调入，期间进入睡眠等待 IO，醒来后才能继续排队争 CPU，进一步推高 r；
- swap IO 本身又加剧 wa，形成“内存不足 → swap → I/O 等待 → r 堆积 → 调度延迟 → 响应更慢”的恶性循环；
- 用 free -h 和 vmstat -s | grep “page” 查缺页率，确认是否由内存泄漏、缓存配置过大（如 redis maxmemory 未设）或 jvm 堆外内存滥用导致。
别只盯 top，组合命令才是关键
单靠 top 容易误判。遇到 r 长期超标，建议按顺序执行三步：
- 先跑 vmstat 1 5 确认 r、b、wa、cs、si/so 的稳定趋势；
- 再跑 iostat -x 1 5 判断磁盘是否拖后腿；
- 最后用 pidstat -u -w -r 1 5 同时看各进程的 CPU 使用率、上下文切换、内存缺页情况，交叉印证瓶颈点。