关于java:点了下详情系统CPU-100%

53次阅读

共计 1209 个字符,预计需要花费 4 分钟才能阅读完成。

作者:玛奇玛 \
链接: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

看这玩意啥都看不出来,感觉是零碎对象没有开释,在疯狂 GC,然而因为 FULL GC 的时候曾经 STW 了,所以无奈查看到底是哪个线程出了问题。而后过了 10 分钟零碎忽然又好了 …. 梗塞的操作曾经实现,gc 能失常回收了。而后过了两分钟又卡死了,我先重启了零碎,前面再剖析剖析。

等零碎没什么人用的时候,我再试着重现一下问题,关上零碎一顿乱点,后果是点开某个性能的详情时零碎卡住了,CPU 又飚下来了,脍炙人口~ 问题定位到了,再实锤一下之前是不是这个问题,我看了一下 localhost_access_log 日志发现,的确是这个接口卡了一千多秒。

因为离线没什么人应用,所以问题过了很久再裸露进去,看了一下代码,次要是业务逻辑问题,有个参数没传进去,导致 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 开发手册(嵩山版)》最新公布,速速下载!

感觉不错,别忘了顺手点赞 + 转发哦!

正文完
 0