从零排查 Linux 高负载：60 秒快速定位与核心工具实战
【摘要】 在生产环境中，最常遇到的紧急告警莫过于“CPU 飙高”或“Load Average 异常”。面对突发的高负载，盲目重启服务往往会丢失排查现场。遵循标准化的定位流，可以在 60 秒内迅速锁定问题边界（是 CPU 密集、内存泄漏、磁盘 I/O 瓶颈，还是网络阻塞）。一、指标理解：Load Average 与 CPU 使用率的区别排查问题前，必须分清两个最容易混淆的概念：CPU 使用率（CPU U...
在生产环境中，最常遇到的紧急告警莫过于“CPU 飙高”或“Load Average 异常”。面对突发的高负载，盲目重启服务往往会丢失排查现场。遵循标准化的定位流，可以在 60 秒内迅速锁定问题边界（是 CPU 密集、内存泄漏、磁盘 I/O 瓶颈，还是网络阻塞）。
一、指标理解：Load Average 与 CPU 使用率的区别
排查问题前，必须分清两个最容易混淆的概念：
-
CPU 使用率（CPU Utilization）：统计的是 CPU 处于非空闲状态的时间比例（计算密集型任务）。
-
平均负载（Load Average）：统计的是处于 可运行状态（R，Running/Runnable） 和 不可中断睡眠状态（D，Uninterruptible Sleep） 的平均进程数。
核心结论：
二、黄金 60 秒排查四步法
登录服务器后，按序执行以下命令，快速缩小故障范围。
1. uptime：观察负载趋势
Bash
uptime
# 输出示例：
# 14:20:15 up 45 days, 2:10, 3 users, load average: 12.45, 8.12, 3.05
-
对比 1 分钟、5 分钟、15 分钟的数值：
-
如果 $1\text{ min} > 5\text{ min} > 15\text{ min}$，说明负载正在急剧上升。
-
如果 $1\text{ min} < 15\text{ min}$，说明峰值已经过去，系统处于恢复期。
-
-
基准线：将负载值除以系统逻辑 CPU 核心数（
nproc）。超过 1.0 表示核心处于过载排队状态。
2. mpstat -P ALL 1 1：拆解 CPU 核心消耗
确认是否存在多核利用不均，以及具体的 CPU 耗时类型：
| 指标 | 含义 | 异常时的排查方向 |
%usr |
用户态 CPU | 应用程序业务逻辑、死循环、算法高开销 |
%sys |
内核态 CPU | 高频系统调用、锁争用、上下文切换剧烈 |
%iowait |
等待 I/O | 磁盘瓶颈、文件读写高并发、慢查询刷盘 |
%si |
软中断 | 网卡丢包、网络流量突增、SYN 攻击 |
3. pidstat -u 1 3：精准抓取开销进程
直接找出消耗 CPU 最多的具体进程 ID（PID）：
Bash
pidstat -u 1 3
关注
%CPU 最高的进程。如果发现某个进程占用超过 100%（多线程应用），记下对应的 PID。4. iostat -xz 1 2：验证磁盘瓶颈
如果
uptime 负载高但 CPU 空闲，重点看磁盘 I/O：Bash
iostat -xz 1 2
-
%util：磁盘利用率。如果长期超过 80%~90%，说明磁盘已接近饱和。 -
await：I/O 操作的平均等待时间（毫秒）。固态硬盘（NVMe/SSD）通常应小于 5ms；若机械硬盘该值超过几十毫秒，说明排队积压严重。
三、典型场景深度定位方案
场景 A：应用进程 %usr 持续 100%（以 Java/Go 等服务为例）
定位到具体进程后，需要下钻到具体线程与代码堆栈：
-
查看进程内部哪个线程占用最高：
Bashtop -H -p <PID>记录占用 CPU 最高的线程 ID（TID）。 -
抓取堆栈分析：
-
若为 Java 应用：将 TID 转换为十六进制（
printf "%x\n" <TID>），使用jstack <PID> | grep -A 20 0x<hex_tid>查看具体哪行代码在执行。 -
若为 C/C++/Go 等原生程序：使用
perf生成性能画像：
Bashperf top -p <PID> # 或抓取 30 秒性能数据生成火焰图 perf record -F 99 -p <PID> -g -- sleep 30
-
场景 B：%sys 过高与上下文切换剧烈
如果 CPU 大量时间耗费在内核空间，通常由于线程频繁竞争锁或高频读写小文件：
Bash
# 查看系统每秒的上下文切换次数（cs）与中断次数（in）
vmstat 1 5
-
如果
cs（Context Switch）达到数十万级别，进一步使用pidstat -w 1查看是哪一个进程引起的主动/被动上下文切换：
-
非自愿上下文切换（cswch/s）高：任务争抢 CPU 资源严重，线程数远超核心承载力。
-
自愿上下文切换（nvcswch/s）高：任务在等待 I/O 或锁资源。
-
场景 C：%iowait 异常高
当系统因不可中断睡眠（D 状态）导致 Load 飙升时：
Bash
# 按 I/O 消耗实时排序进程
iotop -oPa
定位到高 I/O 的 PID 后，使用
lsof 确认该进程正在高频操作哪些具体文件：Bash
lsof -p <PID>
四、快速排查速查清单
[发现负载异常]
│
├─► 1. uptime / nproc ──────► 确定过载严重程度与变化趋势
│
├─► 2. mpstat -P ALL 1 ─────► 区分瓶颈类型:
│ ├─ %usr 高 ───────► pidstat -u ──► top -H -p <pid> ──► 分析业务代码
│ ├─ %sys 高 ───────► vmstat 1 ────► pidstat -w ──────► 排查锁竞争/系统调用
│ └─ %iowait 高 ─────► iostat -xz ──► iotop ───────────► 定位慢 I/O 文件
│
└─► 3. free -h / dmesg ─────► 检查是否触发 OOM Killer 或内核告警
掌握这套以“现象拆解 $\rightarrow$ 瓶颈定性 $\rightarrow$ 线程级下钻”的闭环流程，即可在生产环境故障发生时快速切中要害，避免盲目猜测。
【声明】本内容来自华为云开发者社区博主，不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）