真实 vmstat 数据做一次“生产级判读”

我们直接按你这段 真实 vmstat 数据做一次“生产级判读”（不讲理论，直接落地结论 + 下一步怎么查）。

---

✔ 一、先给结论（非常关键）

你的系统当前状态是：

CPU 高负载 + 调度压力非常明显 + 不是 IO 问题

---

✔ 二、逐行拆解你的 vmstat

✔ 关键数据（稳定段）

r: 131 → 110 → 72 → 71
b: 0
us: 57 → 70 → 70 → 70
sy: 20 → 19 → 19 → 19
id: 24 → 11 → 11 → 12
wa: 0
cs: 0 → 460k → 466k → 479k
in: 0 → 433k → 418k → 409k

---

✔ 三、核心判断（直接结论）

✔ 1）CPU绝对压力很大

关键指标：

r = 70~130
CPU = 90%+（us+sy）
idle = 10~24%

👉 说明：

• CPU 已经接近饱和

• runnable 队列非常长（严重排队）

---

✔ 2）不是 IO 问题（已排除）

b = 0
wa = 0
si/so = 0

👉 结论：

❌ IO完全不是瓶颈

---

✔ 3）严重调度风暴（非常关键）

cs = 430k ~ 480k / s

👉 这是极高值：

cs/s	级别
<10k	正常
10k~50k	偏高
>100k	异常
>300k	严重调度风暴（你现在）

---

✔ 4）中断压力也存在

in = 400k+ / s

👉 说明：

• 网络 / IO中断很重

• 或 softirq 风暴

---

✔ 四、系统本质画像（重点）

你的系统不是简单 CPU 满，而是：

CPU饱和 + 调度风暴 + 中断风暴叠加型负载

---

✔ 五、三大可能根因（按概率排序）

✔ ① 线程过多 / 线程抖动（最高概率）

特征匹配：

• r 很高（70~130）

• cs 极高（400k+）

• CPU不完全100%

👉 典型原因：

• 线程池过大

• 短生命周期线程

• GC / runtime 抖动

• 大量 HTTP 并发线程

---

✔ ② 锁竞争（futex 风暴）

特征：

• sy 19~20%（不低）

• cs 极高

• CPU未完全打满

👉 常见：

• Java synchronized

• Redis client lock

• DB连接池竞争

• 分布式锁抖动

---

✔ ③ 中断/网络风暴（次要但可能叠加）

特征：

• in 400k+

• cs 同时很高

👉 常见：

• 网卡 PPS 高

• Redis/MQ流量突发

• 内核 softirq 压力

---

✔ 六、下一步必须做什么（按优先级）

---

✔ Step 1：找“谁在吃 CPU + 制造 cs”

pidstat -u -w 1

重点看：

• %CPU

• cswch/s

• nvcswch/s

---

✔ 目标

找出：

前 5 个 cs/s 最高的进程

---

✔ Step 2：确认是否线程风暴

top -H

看：

• 是否某个进程线程数爆炸

• 是否大量短线程

---

✔ Step 3：锁竞争确认（关键）

pidstat -w -p ALL 1

如果看到：

nvcswch/s 很高

👉 基本锁问题确定

---

✔ Step 4：perf 定根因（必须做）

---

✔ CPU热点

perf top

---

✔ 调度风暴（你这个case很重要）

perf sched record
perf sched latency

---

✔ 锁竞争确认

perf lock record
perf lock report

---

✔ 中断确认

cat /proc/interrupts

---

✔ 七、你的系统当前“结构性问题总结”

你的 vmstat 已经说明不是单点问题，而是：

✔ 1）CPU已经接近极限

• us + sy ≈ 90%

---

✔ 2）调度系统已经崩边

• cs ≈ 450k/s（极高）

---

✔ 3）线程竞争非常严重

• r 很高（排队）

---

✔ 4）IO完全不是问题

• wa = 0

---

✔ 八、最终诊断（一句话）

这是一个典型的 “CPU饱和 + 线程/锁导致的调度风暴型 load”

---

✔ 九、处理建议（生产级）

✔ 立即措施（止血）

• 限流（QPS / 并发）

• 降线程池大小

• 暂停非核心任务

• 关闭批处理任务

---

✔ 中期优化

• 减少线程数

• 优化锁（减少 synchronized / mutex）

• 使用无锁队列 / CAS

• 减少上下文切换

---

✔ 长期优化

• 拆服务

• 限流架构

• 异步化

• 批处理合并

---

✔ 十、如果你要继续深入（建议下一步）

你可以把下面两条输出贴出来，我可以帮你直接“定位到代码级原因”：

pidstat -u -w 1

perf top

我可以进一步帮你判断：

是 Java 线程池问题 / 锁问题 / Netty / Redis / DB / GC / 内核调度问题中的哪一种。