网站导航
> 技术文档 > 如何排查服务器 CPU 飙高_服务器cpu过高排查

如何排查服务器 CPU 飙高_服务器cpu过高排查

网友: 技术文档 2025-07-26 20:35:59

服务器 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 查看进程内的线程 CPU 占用（-H 显示线程）。
  • ​Java 应用​：使用 jstack 生成线程转储，结合 grep 过滤阻塞或运行中的线程： 
    jstack  | 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 查看 GC 频率（FGC 频繁且 GCT 占比高），可能是内存泄漏或大对象分配导致。

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

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

strace -p  -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  (a java.lang.Object) which is held by \"Thread-0\"\"Thread-0\": locked  (a java.lang.Object) waiting to lock  (a java.lang.Object)

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

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

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

perf top -p  # 实时查看进程的热点函数（如锁获取/释放）
​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 配置检查

​四、注意事项​

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

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

网络标签：

相关问题