cpu 负载过高异常排查

目录

top命令：

定位具体的异常业务

定位异常线程及具体代码行

---

top命令：

登录到服务器使用top命令确认服务器的具体情况

​

top - 18:23:14 up 15 days,  3:21,  1 user,  load average: 1.91, 1.87, 1.68

Tasks: 202 total,   1 running, 201 sleeping,   0 stopped,   0 zombie

Cpu(s): 11.6%us,  5.0%sy,  0.0%ni, 82.4%id,  0.0%wa,  0.0%hi,  0.9%si,  0.1%st

Mem:   8057844k total,  7900088k used,   157756k free,   260704k buffers

Swap:  4192924k total,        0k used,  4192924k free,  2638024k cached

 

第一行是任务队列信息，同 uptime 命令的执行结果。其内容如下：

符号	含义
18:52:04	当前时间
up 10days, 3:49	系统运行时间，格式为：天，时:分
1 user	当前登录用户数
load average: 0.00, 0.01, 0.05	系统负载，即任务队列的平均长度。三个数值分别为 1分钟、5分钟、15分钟前到现在的平均值

 

第二、三行为进程和CPU的信息。当有多个CPU时，这些内容可能会超过两行。内容如下：

符号	含义
total	进程总数
running	正在运行的进程数
sleeping	睡眠的进程数
stopped	停止的进程数
zombie	僵尸进程数
%Cpu(s)
0.0 us	用户空间占用CPU百分比
0.1 sy	内核空间占用CPU百分比
0.0 ni	用户进程空间内改变过优先级的进程占用CPU百分比
98.7 id	空闲CPU百分比;
0.0 wa	等待输入输出的CPU时间百分比
0.0 hi	硬件CPU中断占用百分比
0.0 si	软中断占用百分比
0.0 st	虚拟机占用百分比

最后两行为内存信息。内容如下：

符号	含义
KiB Mem
7993560 total	物理内存总量
207064 free	空闲内存总量
723688 used	使用的物理内存总量
7062808 buffer/cache	用作内核缓存的内存量
KiB Swap
8257532 total	交换区总量
8257356 free	空闲交换区总量
176 used	使用的交换区总量
6479580 avail Mem	缓冲的交换区总量,内存中的内容被换出到交换区，而后又被换入到内存，但使用过的交换区尚未被覆盖，该数值即为这些内容已存在于内存中的交换区的大小,相应的内存再次被换出时可不必再对交换区写入

 

​

进程信息区统计信息区域的下方显示了各个进程的详细信息。首先来认识一下各列的含义。

序号	列名	含义
a	PID	进程id
b	PPID	父进程id
c	RUSER	Real user name
d	UID	进程所有者的用户id
e	USER	进程所有者的用户名
f	GROUP	进程所有者的组名
g	TTY	启动进程的终端名。不是从终端启动的进程则显示为 ?
h	PR	优先级
i	NI	nice值。负值表示高优先级，正值表示低优先级
j	P	最后使用的CPU，仅在多CPU环境下有意义
k	%CPU	上次更新到现在的CPU时间占用百分比（进程占用单核cpu的时间占比）
l	TIME	进程使用的CPU时间总计，单位秒
m	TIME+	进程使用的CPU时间总计，单位1/100秒
n	%MEM	进程使用的物理内存百分比
o	VIRT	进程使用的虚拟内存总量，单位kb。VIRT=SWAP+RES
p	SWAP	进程使用的虚拟内存中，被换出的大小，单位kb。
q	RES	进程使用的、未被换出的物理内存大小，单位kb。RES=CODE+DATA
r	CODE	可执行代码占用的物理内存大小，单位kb
s	DATA	可执行代码以外的部分(数据段+栈)占用的物理内存大小，单位kb
t	SHR	共享内存大小，单位kb
u	nFLT	页面错误次数
v	nDRT	最后一次写入到现在，被修改过的页面数。
w	S	进程状态(D=不可中断的睡眠状态,R=运行,S=睡眠,T=跟踪/停止,Z=僵尸进程)
x	COMMAND	命令名/命令行
y	WCHAN	若该进程在睡眠，则显示睡眠中的系统函数名
z	Flags	任务标志，参考 sched.h

top 按1后显示每个核的cpu使用情况
​

 

定位具体的异常业务

这里咱们可以使用 pwdx 命令根据 pid 找到业务进程路径，进而定位到负责人和项目：

​​

可得出结论：该进程对应的就是sqs服务

 

定位异常线程及具体代码行

1.执行top -c命令，找到cpu最高的进程的id

    2.执行top -H -p pid，这个命令就能显示刚刚找到的进程的所有线程的资源消耗情况。找到CPU负载高的线程pid 8627, 把这个数字转换成16进制，21B3（10进制转16进制，用linux命令: printf %x 8627）。

    3.执行jstack -l pid，拿到进程的线程dump文件。这个命令会打出这个进程的所有线程的运行堆栈。

    4.用记事本打开这个文件，搜索“21B3”，就是搜一下16进制显示的线程id。搜到后，下面的堆栈就是这个线程打出来的。排查问题从这里深入。

    今天最后排查出来的结果是“VM THREAD”把进程的资源耗尽。那只能说明是jvm在耗cpu。很容易想到是疯狂的GC，按关键字 “overhead” 搜一下系统日志， 发现 “java.lang.OutOfMemoryError: GC overhead limit exceeded”日志。问题明了了。jvm在疯狂的Full GC，而且有个大对象始终根节点路径可达，无法释放。dump了一下这个实例的内存，发现确实有大对象，占用了一个多G的堆内存。

 

 

 

传统的方案一般是4步：

1. top + P 按cpu占比排序 +M 按内存占比排序 // 首先按进程负载排序找到 maxLoad(pid)

2. top -Hp 进程PID：1073 // 找到相关负载 线程PID

3. printf “0x%x\n”线程PID： 0x431 // 将线程PID转换为 16进制，为后面查找 jstack 日志做准备

4. jstack 进程PID | vim +/十六进制线程PID - // 例如：jstack 1040|vim +/0x431