点了下详情系统,CPU 100%。。。

作者:玛奇玛 \
链接:https://juejin.cn/post/7233307834456129593

又是一个百无聊赖的早晨,我在快乐地摸鱼,工作群响了:离线系统登录不上了。我第一反应是不科学啊,系统已经很久改动过了...赶紧上生产环境看看,CPU高达1200%。接着又是熟练地敲出那几行排查CPU过高的命令:

top -H -p  pid 查看java占用率最高的几条线程
jstack pid >  xxx.txt   打印线程快照
jmap -heap pid   查看堆内存情况

推荐一个开源免费的 Spring Boot 实战项目:

https://github.com/javastacks/spring-boot-best-practice

点了下详情系统,CPU 100%。。。_第1张图片

点了下详情系统,CPU 100%。。。_第2张图片

点了下详情系统,CPU 100%。。。_第3张图片

看这玩意啥都看不出来,感觉是系统对象没有释放,在疯狂GC,但是因为FULL GC的时候已经STW了,所以无法查看到底是哪个线程出了问题。然后过了10分钟系统突然又好了....堵塞的操作已经完成,gc能正常回收了。 然后过了两分钟又卡死了,我先重启了系统,后面再分析分析。

等系统没什么人用的时候,我再试着重现一下问题,打开系统一顿乱点,结果是点开某个功能的详情时系统卡住了,CPU又飚上去了,喜闻乐见~问题定位到了,再实锤一下之前是不是这个问题,我看了一下localhost_access_log日志发现,确实是这个接口卡了一千多秒。

点了下详情系统,CPU 100%。。。_第4张图片

因为离线没什么人使用,所以问题过了很久再暴露出来,看了一下代码,主要是业务逻辑问题,有个参数没传进去,导致sql要查很久,查到了几百万的数据,gc也无法回收。

复盘

一开始我以为是某个接口调了很多次并发太高导致的,没想到点一下详情系统就挂了。。我们可以看到CPU在GC回收的时候STW,是没有线程能占用到CPU的,所以top -H -p pid 只能看到CPU全被GC线程占用了。如果是某个接口并发太高导致的,我们可以看jstack线程快照,里面是会有这个接口在执行的记录。

还有一个问题就是说系统GC卡了10-20分钟,却没有报OOM,还是一直在堵塞状态,后面还正常了一小会,这个是需要看堆内存的情况..因为比较难排查所以只是通过现象知道GC还是可以回收一点点垃圾的

总结

1、CPU100%的时候可以打印线程快照jstack pid,查看是哪个线程占用了CPU,一般都是某个业务线程阻塞无法进行GC回收导致。

2、可以查看localhost_access_log查看系统接口用时,一般用时很久的都是有问题的接口。

3、记得看业务代码参数有没有漏传,如果漏传参数可能会导致全表扫描直接卡死系统。

近期热文推荐:

1.1,000+ 道 Java面试题及答案整理(2022最新版)

2.劲爆!Java 协程要来了。。。

3.Spring Boot 2.x 教程,太全了!

4.别再写满屏的爆爆爆炸类了,试试装饰器模式,这才是优雅的方式!!

5.《Java开发手册(嵩山版)》最新发布,速速下载!

觉得不错,别忘了随手点赞+转发哦!

你可能感兴趣的:(java)