当前位置：首页 > news >正文

如何排查服务器 CPU 飙高

news 2025/7/23 8:35:27

服务器 CPU 飙高（CPU 使用率持续超过 80% 甚至接近 100%）是典型的性能瓶颈问题，可能由应用逻辑缺陷、资源竞争、外部压力或硬件/系统异常引起。以下是系统化的排查步骤，覆盖从现象确认到根因定位的全流程。

一、确认 CPU 飙高的现象与范围

首先需明确 CPU 高负载的具体表现和影响范围，避免误判：

1. 区分用户态（User）与内核态（System）CPU

通过 top 或 htop 查看 CPU 使用率细分：

用户态（User）：应用程序代码执行占用的 CPU（如业务逻辑、计算）。
内核态（System）：操作系统内核执行占用的 CPU（如 I/O 调度、网络协议栈、进程调度）。

关键结论：

若用户态 CPU 高：问题通常在应用程序（如死循环、频繁计算）。
若内核态 CPU 高：问题可能在 I/O 阻塞、网络流量过大或系统调用频繁。

2. 确认是持续高负载还是间歇性高负载

持续高负载：可能是应用逻辑缺陷（如死循环）、内存泄漏导致频繁 GC，或外部持续压力（如 DDoS 攻击）。
间歇性高负载：可能是批量任务（如定时任务）、突发流量（如秒杀活动）或资源竞争（如锁争用）。

3. 定位高负载的进程/线程

使用工具锁定具体是哪个进程或线程占用了大量 CPU：

(1) 系统级工具：top/htop

top 命令：按 P 键按 CPU 使用率排序，找到占用最高的进程（PID）。
```
top -c  # 显示完整命令行
```
htop（更友好的交互式工具）：支持树形查看进程关系，按 F6 选择排序方式（如 CPU 占用）。

(2) 进程级工具：pidstat

通过 pidstat 查看进程的 CPU 使用细节（需安装 sysstat 包）：

pidstat -u 1 5  # 每 1 秒输出一次，共 5 次，显示进程的 CPU 使用率

(3) 线程级工具：top -H 或 jstack（Java 应用）

非 Java 应用：通过 top -H -p <PID> 查看进程内的线程 CPU 占用（-H 显示线程）。
Java 应用：使用 jstack <PID> 生成线程转储，结合 grep 过滤阻塞或运行中的线程：
```
jstack <PID> | grep -A 20 "java.lang.Thread.State: RUNNABLE"  # 查看运行中的线程
```

二、分析高 CPU 进程的具体原因

锁定高 CPU 进程后，需深入分析其内部逻辑或外部交互，常见原因及排查方法如下：

1. 应用程序逻辑缺陷（用户态 CPU 高）

典型场景：死循环、递归未终止、频繁计算（如加密/压缩）、错误的分页查询（全表扫描）。

(1) Java 应用：检查线程状态与调用栈

死循环/无限递归：线程转储中若大量线程处于 RUNNABLE 状态，且调用栈显示重复方法（如 while(true) 循环），可能是死循环。
示例（死循环）：

"http-nio-8080-exec-1" #12 prio=5 os_prio=0 tid=0x00007f8e3c0b8000 nid=0x4567 runnable [0x00007f8e2c1fe000]java.lang.Thread.State: RUNNABLEat com.example.DeadlockDemo.infiniteLoop(DeadlockDemo.java:20)  # 重复调用自身...

频繁 GC：通过 jstat -gcutil <PID> 查看 GC 频率（FGC 频繁且 GCT 占比高），可能是内存泄漏或大对象分配导致。

(2) 非 Java 应用：检查进程调用栈

使用 strace（Linux）跟踪进程的系统调用，定位耗时操作：

strace -p <PID> -c  # 统计系统调用耗时（-c 显示统计）

若发现大量 read()、write() 或 poll() 调用，可能是 I/O 阻塞或网络流量过大。

2. I/O 阻塞导致内核态 CPU 高

典型场景：磁盘 I/O 慢（如机械盘 vs SSD）、网络 I/O 阻塞（如大量未完成的 Socket 连接）、文件描述符耗尽。

(1) 磁盘 I/O 问题

使用 iostat 查看磁盘 I/O 利用率（%util 接近 100% 表示磁盘满负荷）：
```
iostat -d 1 5  # 每 1 秒输出一次磁盘 I/O 统计
```
若 %util 高且 await（平均 I/O 等待时间）大，可能是磁盘性能不足或存在大量随机读写（如数据库日志写入）。

(2) 网络 I/O 问题

使用 netstat 或 ss 查看网络连接状态（如大量 TIME_WAIT 或 ESTABLISHED 连接）：
```
ss -ant | grep ESTAB  # 查看已建立的 TCP 连接数
```
若连接数过多（如超过 ulimit -n 限制），可能导致进程阻塞在 accept() 或 connect()，间接推高内核态 CPU。

3. 锁竞争与线程争用

典型场景：多个线程竞争同一把锁（如 synchronized、ReentrantLock），导致线程频繁阻塞/唤醒。

(1) Java 应用：检查锁竞争

使用 jstack 查看线程的锁持有与等待关系（locked 和 waiting to lock 字段）：

"Thread-1":waiting to lock <0x000000076b45a2c0> (a java.lang.Object)which is held by "Thread-0""Thread-0":locked <0x000000076b45a2c0> (a java.lang.Object)waiting to lock <0x000000076b45a290> (a java.lang.Object)

此片段表明线程 Thread-0 和 Thread-1 互相等待对方持有的锁，形成锁竞争。

(2) 非 Java 应用：使用 `perf` 分析

Linux 下使用 perf 工具分析锁竞争（需 root 权限）：

perf top -p <PID>  # 实时查看进程的热点函数（如锁获取/释放）

4. 外部压力：突发流量或恶意请求

典型场景：DDoS 攻击、批量任务（如定时任务并发执行）、爬虫高频访问。

(1) 检查网络流量

使用 iftop 或 nload 查看网络带宽占用（如某个 IP 发送大量请求）：
```
iftop -i eth0  # 实时显示网络接口流量
```

(2) 检查应用日志

查看 Web 服务器（如 Nginx、Tomcat）的访问日志，统计高频请求的 URL 或 IP：

grep "GET /api" access.log | awk '{print $1}' | sort | uniq -c | sort -nr  # 统计 IP 访问次数

5. 硬件或系统异常

典型场景：CPU 本身故障（如过热降频）、BIOS 配置错误、内核模块冲突。

(1) 检查 CPU 温度与风扇

使用 sensors 工具（需安装 lm-sensors 包）查看 CPU 温度：
```
sensors  # 显示 CPU 核心温度（如 Core 0: +85°C）
```
若温度过高（超过 90°C），可能是散热不良导致 CPU 降频（性能下降但功耗高）。

(2) 检查内核日志

查看 /var/log/syslog 或 /var/log/kern.log，寻找硬件错误或异常：

dmesg | grep -i "error\|warning"  # 显示内核错误/警告信息

三、总结：排查流程与工具链

步骤	目标	关键工具/命令
确认 CPU 飙高现象	区分用户态/内核态，定位进程/线程	`top`、`htop`、`pidstat`
分析高负载进程	锁定具体应用或服务	`jstack`（Java）、`strace`（非 Java）
排查应用逻辑缺陷	死循环、频繁计算、GC 问题	线程转储、`jstat -gcutil`、代码审查
排查 I/O 阻塞	磁盘/网络 I/O 慢、连接数过多	`iostat`、`ss`、`netstat`
排查锁竞争与线程争用	线程互相等待锁	`jstack`（锁持有/等待关系）、`perf`（非 Java）
排查外部压力	突发流量、恶意请求	`iftop`、`nload`、访问日志分析
检查硬件/系统异常	CPU 故障、散热问题、内核错误	`sensors`、`dmesg`、BIOS 配置检查