线上CPU Load飙高如何排查？

线上CPU Load飙高是系统性能故障的常见场景，需要通过系统化的排查流程定位根本原因。以下是从概念区分到具体排查步骤的详细说明：

一、核心概念：CPU Load与CPU使用率的区别

CPU Load（负载）

指单位时间内等待CPU资源的进程数，反映系统的繁忙程度，通常取1分钟、5分钟、15分钟的平均值（如top命令中的load average）。
合理负载范围：一般认为负载值 ≤ CPU核心数时属于正常，超过则表示任务排队等待。

CPU使用率

指CPU在用户空间（user）、内核空间（system）、空闲（idle）、IO等待（iowait）等状态的时间占比。
高Load可能伴随高CPU使用率，但也可能由IO瓶颈、进程阻塞等非CPU因素导致（如iowait过高时，Load也会升高）。

二、排查流程：从系统到进程的逐层定位

1. 第一步：确认系统整体负载情况

工具：top或htop

关键观察点：

顶部load average是否超过CPU核心数（如4核CPU，负载>4则需警惕）。
CPU状态分布：重点已关注us（用户空间）、sy（内核空间）、wa（IO等待）的占比。

us高：可能是应用代码逻辑复杂（如死循环、高计算量）。
sy高：可能是内核调用频繁（如系统调用过多、驱动问题）。
wa高：可能是磁盘IO瓶颈（如大量读写操作阻塞进程）。

示例输出分析：

load average: 8.56, 7.23, 6.10  # 3个值均高于4核CPU的合理范围
CPU(s):  92.0% us,  5.0% sy,  0.0% ni,  2.0% id,  1.0% wa  # us高，sy正常

结论：用户空间进程消耗大量CPU，需定位具体进程。

2. 第二步：定位高负载进程

工具：top（按P键按CPU使用率排序）、ps -eo pid,ppid,%cpu,command

操作步骤：

在top中找到CPU使用率最高的进程PID（如1234）。
用ps -ef | grep 1234查看进程所属用户和命令行，判断是否为核心业务进程。
若为Java进程，可结合jps -l确认进程名称（如java -jar app.jar）。

特殊情况：

若top中无高CPU进程但Load很高，可能是内核线程（kthread） 或僵尸进程导致，可用ps -e -o stat,ppid,pid,command | grep -w defunct检查僵尸进程。

3. 第三步：分析进程内部问题

场景A：用户空间进程（如Java、C++程序）

工具：

strace -p PID：查看进程的系统调用耗时（若sy高时常用）。
perf top -p PID：分析进程内热点函数（需安装perf工具）。
Java进程专属：

jstack PID：查看线程栈，定位死循环、锁竞争（如WAITING/BLOCKED状态线程）。
jmap -histo:live PID：分析内存对象分布，排查内存泄漏导致的GC频繁。
jstat -gc PID：监控GC频率和耗时，若GC频繁且Load高，可能是内存不足导致STW（Stop The World）。

示例：Java线程栈分析

"thread-1" #12 prio=5 os_prio=0 tid=0x0001 nid=0x4567 runnable
  at com.example.LoopTask.run(LoopTask.java:45)  # 发现死循环代码行

结论：LoopTask类的第45行存在无限循环，导致CPU飙升。

场景B：内核空间问题（如驱动、系统调用）

工具：perf top -k（分析内核函数热点）、dmesg | grep error（查看内核日志错误）。
常见原因：

网卡驱动异常导致中断处理耗时过高（可用watch -d cat /proc/interrupts观察中断计数）。
文件系统调用频繁（如大量小文件读写，可用lsof | wc -l查看打开文件数）。

4. 第四步：排查系统资源瓶颈

磁盘IO：iostat -x 1

重点看%util（磁盘利用率）和await（IO平均等待时间），若%util>70%且await>50ms，可能是磁盘瓶颈。

内存：free -h、vmstat

若可用内存（free）不足，系统会频繁swap，导致wa升高和Load飙高。

网络：iftop、netstat -anp

检查是否有异常流量（如DDOS攻击）或大量连接等待（TIME_WAIT状态过多）。

5. 第五步：结合业务场景和历史数据

监控系统查询：
通过Prometheus、Zabbix等查看CPU Load的历史趋势，是否有周期性峰值（如定时任务、日志切割触发）。
代码变更关联：
检查问题发生时间点是否有新版本部署、配置变更，重点排查新增代码中的循环、递归逻辑。
外部因素：
确认是否有突发流量、数据库慢查询导致应用层负载升高（如缓存失效击穿DB）。