CPU 飙高 ≠ 服务器真的卡？

一次生产事故，带你看懂 Linux CPU、Load、IO、软中断的真相

CPU 100% 了，服务器是不是要挂了？ 很多运维、开发一看到 top 里 CPU 拉满，第一反应就是： 👉 “赶紧 kill 进程 / 扩容 / 重启！” 但在真实生产环境里： CPU 高，往往不是 CPU 的问题。

这篇文章不讲基础命令堆砌，而是结合真实生产事故，带你一步步拆解：

• CPU 利用率 vs Load 到底差在哪？
• 为什么 CPU 不高，Load 却爆了？
• %wa、%si、%st 各自意味着什么？
• 没有“异常进程”，CPU 却持续报警，该怎么查？

一、真实生产事故：CPU 80%，Load 却 40+

背景

• 4 核 8G 云服务器
• 业务：Java API + MySQL
• 现象：
  • CPU 使用率：60%～80%
  • Load Average：40 / 38 / 35
  • 接口大量超时

很多人第一步会做什么？

top

看到结果却懵了👇

• 没有单进程吃满 CPU
• Java 进程 CPU 也就 200%（4 核）
• MySQL CPU 很低

那 Load 40 是哪来的？

二、先把概念说清楚：CPU 利用率 vs Load

1️⃣ CPU Utilization（CPU 使用率）

CPU 有多忙？

• 统计的是：CPU 时间都花在哪
• 典型字段（top / sar）：
  • us：用户态
  • sy：内核态
  • wa：IO 等待
  • si：软中断
  • st：被虚拟化偷走的时间

📌 CPU 100% ≠ 系统一定慢

2️⃣ Load Average（系统负载）

有多少任务在抢 CPU 或等 CPU？

Load 统计的是：

• 正在运行的进程
• + 等 CPU 的进程
• + 等 IO 的进程（D 状态）

👉 所以关键一句话：

Load 高，可能是 CPU 不够，也可能是 IO 把进程“堵”住了。

三、关键一步：看 CPU 时间都去哪了（别只看 %CPU）

在事故机器上执行：

top

重点看这一行：

%Cpu(s): 25 us, 10 sy, 0 ni, 55 id, 10 wa, 0 hi, 0 si, 0 st

你会发现一个危险信号👇

wa = 10%

这意味着什么？wa意味着CPU在等IO时间。

四、CPU 在“等 IO”，不是在“干活”

1️⃣ IO 等待为什么会拉高 Load？

当进程：

• 访问磁盘
• 访问网络存储
• MySQL 等待磁盘返回

这些进程会进入 D 状态（不可中断）：

ps -eo pid,stat,cmd | grep D

📌 D 状态进程会被算进 Load！

所以出现经典现象：

❌ CPU 并不忙 ❌ 但进程全在排队 ❌ Load 飙升 ❌ 业务接口超时

2️⃣ 用 vmstat 一眼识别 IO 型“假 CPU 高”

vmstat 2

重点看：

r  b   us sy wa id
2  20  20 10 50 20

解释👇

b 很大 + wa 很高 = IO 拖垮系统

五、继续深挖：是磁盘慢，还是 MySQL 作妖？

1️⃣ 磁盘层确认（iostat）

iostat -x 2

重点字段：

• %util → 是否接近 100%
• await → IO 响应时间
• svctm → 服务时间

📌 事故机器中：

• %util 长期 95%+
• await 飙到 200ms

2️⃣ 最终原因（真实）

MySQL 慢 SQL + 单磁盘 + 大量随机 IO

• 索引缺失
• 表数据暴涨
• SSD 被打满
• 所有请求阻塞

👉 CPU 看起来“没事”， 👉 但业务已经“半死”。

六、为什么 top / ps 看不出问题？

这是很多人最容易踩的坑。

❌ 误区

• “CPU 不高，应该没事”
• “没看到异常进程”

✅ 真相

• top 显示的是 消耗 CPU 时间
• IO 阻塞进程 不消耗 CPU
• 但它们：
  • 堵线程
  • 占连接
  • 拉高 Load
  • 拖垮系统响应

七、生产级排查顺序

这是我在生产环境固定使用的顺序

① 一眼看趋势

uptime

• Load 是否持续升高？
• 是否超过 CPU 核数 × 2？

② 看 CPU 时间分布 top 重点不是进程，而是：

• us / sy / wa / si / st

③ 判断是不是 IO 问题 vmstat 2 iostat -x 2 ④ 精确定位进程 ps -eo pid,stat,pcpu,cmd | sort -k3 -r | head ⑤ 再看业务本身

• 慢 SQL
• 接口并发
• 线程池是否打满
• GC 是否频繁（Java）

八、生产中的解决方案 ✅ 短期止血

• 限流 / 熔断
• kill 问题 SQL
• 临时重启服务（慎用）

✅ 中期优化

• SQL 索引优化
• IO 拆盘 / 升级 SSD
• 服务拆分（MySQL、日志）

✅ 长期方案

• 监控 CPU + Load + IO 三件套
• 设置：
  • wa 告警
  • Load 持续阈值
• 引入 APM / 慢 SQL 分析 九、送给大家一句话 CPU 飙高不是问题， 看不懂 CPU，才是问题。