如何排查服务器 CPU 飙高

服务器 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: RUNNABLE
      at 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"  # 显示内核错误/警告信息

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

​四、注意事项​

• ​生产环境谨慎操作​：避免在业务高峰期重启进程或修改配置，优先通过监控工具（如 Prometheus+Grafana）实时观察。
• ​日志与监控结合​：通过日志（如应用日志、系统日志）和监控（CPU、内存、磁盘 I/O）交叉验证，避免误判。
• ​逐步缩小范围​：从系统→进程→线程→代码/配置，逐层定位根因，避免盲目修改。

通过以上步骤，可高效排查服务器 CPU 飙高的问题，最终定位到具体的应用逻辑缺陷、资源竞争或外部压力，并针对性优化。