【运维排查】服务器CPU飙升100%?别慌,教你3步精准定位“罪魁祸首”

简介: 当服务器CPU飙高时,别急着重启!本文教你四步精准排查:用`top`定位高占用进程,`top -Hp`找出耗CPU线程,`printf`转十六进制,再通过`jstack`结合线程ID定位到具体代码行。快速锁定死循环、频繁GC或复杂计算等问题根源,成为团队中的故障排查高手。

前言

“滴滴滴...” 手机突然收到阿里云云监控的报警短信:“您的ECS实例 CPU使用率已超过 90%”

此时,你的服务可能响应缓慢,甚至直接502。面对这种情况,很多新手的反应是直接重启服务器。虽然重启能暂时解决问题,但找不到根因,问题迟早会卷土重来。

今天,我将分享一套**“教科书级”**的CPU飙高排查思路,只需几行命令,就能精准定位到是哪一行代码搞崩了服务器。

第一步:全局定位——找到耗资源的进程 (PID)

首先,我们需要知道是哪个程序(进程)占用了CPU。

  1. 在终端输入 top 命令。
  2. 进入界面后,按下大写 P 键,系统会按照 CPU使用率 对进程进行降序排列。

Bash

top - 14:28:32 up 10 days,  3:14,  2 users,  load average: 2.10, 1.05, 0.56
Tasks: 102 total,   1 running, 101 sleeping,   0 stopped,   0 zombie
%Cpu(s): 98.5 us,  1.2 sy,  0.0 ni,  0.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
PID    USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
12345  root      20   0   2.5g   500m   10m S  99.0 20.5   10:15.20 java

分析:如上图所示,PID为 12345java 进程CPU占用率高达 99.0%,它就是我们要找的目标。

第二步:深度挖掘——找到耗资源的线程 (TID)

一个进程往往包含多个线程,我们需要知道具体是哪个线程在“作恶”。

使用命令 top -Hp <PID>,其中 <PID> 替换为上一步找到的进程ID。

Bash

# 查看进程 12345 下的所有线程
top -Hp 12345

进入界面后,同样按下 P 键排序:

Bash

PID    USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
12368  root      20   0   2.5g   500m   10m R 95.5  0.0   05:10.20 java
12369  root      20   0   2.5g   500m   10m S  1.2  0.0   00:05.10 java

分析:我们发现 PID(在线程视图中其实是 Thread ID)为 12368 的线程占用了绝大部分CPU。

第三步:进制转换——准备定位代码

Linux中的线程ID是十进制的(如 12368),而在Java堆栈日志中,线程ID通常是以十六进制(Hex)显示的。我们需要进行一次转换。

可以使用 printf 命令:

Bash

# 将 12368 转换为十六进制
printf "%x\n" 12368

输出:3050

记下这个十六进制数字:0x3050

第四步:真相大白——定位具体代码行数

现在我们有了进程ID(12345)和十六进制的线程ID(0x3050),就可以使用 Java 自带的 jstack 工具来导出堆栈信息,并抓取“案发现场”。

Bash

# 打印堆栈信息,并使用 grep 查找 0x3050,显示匹配行的后 20 行
jstack 12345 | grep "0x3050" -A 20

输出示例:

"Thread-5" #25 prio=5 os_prio=0 tid=0x00007f8... nid=0x3050 runnable [0x00007f8...]
   java.lang.Thread.State: RUNNABLE
    at com.example.demo.controller.TestController.loop(TestController.java:28)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    ...

终极分析:仔细看输出日志的 at com.example.demo.controller.TestController.loop(TestController.java:28)。 真相只有一个:TestController.java 文件的第 28 行

通常这里可能存在:

  1. 死循环: 代码逻辑错误导致 while(true) 且没有退出条件。
  2. 频繁GC: 如果看到是 GC task thread 占用高,说明内存泄露导致了频繁的 Full GC。
  3. 复杂计算: 大量的数学运算或加密解密操作。

总结

以后遇到 CPU 100% 的情况,不要慌,按照这个套路走:

  1. top → 找 进程ID (PID)
  2. top -Hp PID → 找 线程ID (TID)
  3. printf "%x\n" TID → 转 十六进制 (Hex)
  4. jstack PID | grep Hex -A 20 → 找 问题代码

掌握这个排查链路,你就是团队里那个能“秒级定位问题”的专家!

相关文章
|
13天前
|
数据采集 人工智能 安全
|
8天前
|
编解码 人工智能 自然语言处理
⚽阿里云百炼通义万相 2.6 视频生成玩法手册
通义万相Wan 2.6是全球首个支持角色扮演的AI视频生成模型,可基于参考视频形象与音色生成多角色合拍、多镜头叙事的15秒长视频,实现声画同步、智能分镜,适用于影视创作、营销展示等场景。
657 4
|
8天前
|
机器学习/深度学习 人工智能 前端开发
构建AI智能体:七十、小树成林,聚沙成塔:随机森林与大模型的协同进化
随机森林是一种基于决策树的集成学习算法,通过构建多棵决策树并结合它们的预测结果来提高准确性和稳定性。其核心思想包括两个随机性:Bootstrap采样(每棵树使用不同的训练子集)和特征随机选择(每棵树分裂时只考虑部分特征)。这种方法能有效处理大规模高维数据,避免过拟合,并评估特征重要性。随机森林的超参数如树的数量、最大深度等可通过网格搜索优化。该算法兼具强大预测能力和工程化优势,是机器学习中的常用基础模型。
350 164
|
7天前
|
机器学习/深度学习 自然语言处理 机器人
阿里云百炼大模型赋能|打造企业级电话智能体与智能呼叫中心完整方案
畅信达基于阿里云百炼大模型推出MVB2000V5智能呼叫中心方案,融合LLM与MRCP+WebSocket技术,实现语音识别率超95%、低延迟交互。通过电话智能体与座席助手协同,自动化处理80%咨询,降本增效显著,适配金融、电商、医疗等多行业场景。
359 155

热门文章

最新文章