问题
订单服务通过MQ进行订单同步时,刚启动可以正常消费,但是跑一会就会卡住,每次都是第8个kafka分区不行再进行消费,其他分区消费的很慢。
现象
- 首先,CPU超高,达到百分之300多;
- 其次,kafka消息消费很慢,尤其是第八个分区
分析
-
由于CPU告警,首先想到JVM内存溢出了,所以先jstack出内存快照,定位导致内存溢出的代码或者可能的原因,大致过程:
1. 使用top查看系统的资源占用情况
2. 使用ps命令查看进程对应的是哪个程序
3. 使用top -p [PID] -H 观察该进程中所有线程的资源占用
4. 使用jstack查看线程快照
5. 定位出现的问题
参考地址 -
导出内存快照,放到MAT上进行分析,定位到是一个static方法,内存溢出了
但是代码逻辑没有问题,所以一时间没有找到问题。 -
鉴于上面没有分析出来结果,又从GC日志中找结果:
发现频繁的 Young GC,都是失败的。到这里还是没有很好的思路,后来通过打印日志,确认到了一个订单只有70多万个商品,再处理商品的逻辑中又使用了多层for循环进行处理,导致栈内存溢出。
结论
大数据导致内存溢出,在这个大数据处理逻辑中存在不合理代码,所以导致了内存溢出。
在排查的过程中,我们还升高了metaspace的内存,但是还是瞬间被占用满,导致CPU飙升到百分之800左右。一味堆配置并不能一劳永逸的解决问题。
工具
- MAT 进行内存分析
- gceasy进行GC日志分析
参考
java程序CPU使用率高可能的原因
Mat使用详解
内存快照两种方式
- jmap 进行快照导出
输出快照
jmap -dump:format=b,file=/usr/local test1.hprof 2778
- 第二种,直接通过jstack进行查看(先top -h 进程ID - H,查询出线程ID,再转为十六进制的,进而执行下面的命令)
jstack 5739 | grep -A 100 nid=0x1802
材料
gc log