线上机器cpu负载200%告警排查

CPU告警排查思路，正常情况就是如下两种情况

• 执行任务的java线程本身存在bug，死循环或者操作本身耗cpu，导致cpu占用过高
• jvm发生频繁gc，导致cpu过高

查看耗时较高的进程

• top命令，并按大写P以cpu利用率排序，确定cpu占用最高的进程为 java进程

• top -H -p [进程id]，注意：此时的PID为线程ID，如下图所示

• 计算java线程id的16进制值，用jstack看到的线程快照中，线程ID需要转换成小写十六进制值

1. 可以借助在线转换工具：十进制转换 - 在线进制转换器
2. linux系统也可以使用如下命令转换  printf "%x\n" [线程ID] 

printf "%x\n" 22304

使用Jstack查看线程快照

#grep的 -B n 前n行
#grep的 -C n 前后各n行
#grep的 -A n 后n行
jstack [进程ID] |grep [转换后的线程ID] -A 30

分析上图发现，查看完整堆栈定位代码位置，该线程进本都在执行

com.xxx.hub.util.CaseNodeParseUtil.addNodeToChildrenIfParentIdEqual(CaseNodeParseUtil.java:1363)

后续进一步分析，需要结合业务代码查看该部分是否存在耗时

查看GC情况

• 首先使用top查看当前内存的使用情况

• 查看gc次数，使用命令 jstat -gc [Java进程ID]：

结合上图可知YGC次数1232，FGC共468次

如果GC次数很多的情况，基本可以说明存在频繁GC导致cpu占用高的问题

GC参数说明

S0C：第一个幸存区的大小
S1C：第二个幸存区的大小
S0U：第一个幸存区的使用大小
S1U：第二个幸存区的使用大小
EC：伊甸园区的大小
EU：伊甸园区的使用大小
OC：老年代大小
OU：老年代使用大小
MC：方法区大小
MU：方法区使用大小
CCSC:压缩类空间大小
CCSU:压缩类空间使用大小
YGC：年轻代垃圾回收次数
YGCT：年轻代垃圾回收消耗时间
FGC：老年代垃圾回收次数
FGCT：老年代垃圾回收消耗时间
GCT：垃圾回收消耗总时间 

 使用命令dump 内存堆的存储快照，命令如下

jmap -dump:format=b,file=/tmp/mem.hprof [进程ID]

使用内存分析工具，如Eclipse Memory Analyzer等分析mem.hprof文件，分析内存哪部分占用大，存在内存泄露，导致空间无法释放。