前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >CPU占用过高排查实战 原来这么简单

CPU占用过高排查实战 原来这么简单

作者头像
须臾之余
发布2020-10-26 17:20:59
1.4K0
发布2020-10-26 17:20:59
举报
文章被收录于专栏:须臾之余

代码介绍:

jdk提供的工具:

1、在Linux中启动项目:java -cp ref-jvm.jar -XX:+PrintGC -Xms200M -Xmx200M ex13.FullGCProblem

2、top命令,实时显示进程CPU百分比和内存使用情况:可以发现进程7498 占用CPU比较高

等待一段时间:发现CPU使用率在逐渐增加

jinfo:显示JVM参数设置信息

jmap -heap 7498 :可以查看内存使用情况

在不进行任何垃圾回收器指定情况的比例1:1:1

一段时间后 CPU占比很高了

top -p 7498:单独显示7498进程占比CPU

在监控界面输入H,获取当前进程下的所有线程信息

jstack 7498:输出线程信息,nid为16进制

将7500/7501换算成16进制1D4C/1D4D,在界面中查找,问题定位到CPU100%是疯狂的垃圾回收的线程占据的

jstat -gc 7498 2000 10:两秒钟刷新一次GC信息,一共查询10次

各个字段的含义如下:

不够直观,换个方式输出:jstat -gc 7498 5000 20 | awk '{print 13,14,15,16,

可以发现Full GC在增加,,说明内存不够了

jmap -heap 7498,查看堆内存情况,发现老年代使用率很大了,可能发生了内存泄漏

现在我们定位为是内存问题,CPU100%只是它的体现

jmap -histo 7498 | head -20:显示堆空间对应7498进程对应对象占用大小

问题总结(找到问题)

一般来说,前面那几行,就可以看出,到底是哪些对象占用了内存,这些对象回收不掉,导致了Full GC 里面还有OOM 任务数多于线程数,那么任务会进入阻塞队列,就是一个队列,因为代码中任务数一直多于线程数,所以每0.1s,就会有50个任务进入阻塞对象,50个任务底下有对象,至少对象送进去了,但是没执行,所以导致对象一直都在,同时还回收不了。 为什么回收不了,Executor是一个GCRoots,所以堆中,就会有60多万个对象,阻塞队列中60多万个任务,futureTask,并且这些对象还回收不了。

总结

在JVM出现性能问题的时候(表现上是CPU100%,内存一直占用) 1、出现CPU100%,要从两个角度出发,一个有可能是业务线程疯狂运行,比如说死循环,还有就是GC线程在疯狂的回收,因为在JVM中垃圾回收器主流也是多线程的,所以很容易导致CPU100%; 2、在遇到内存溢出的问题的时候,一般情况下我们要查看系统哪些对象占用比较多,在实际业务代码中,找到对应的对象,分析对应的类,找到为啥这些对象不能回收的原因,就是通过可达性分析算法,JVM的内存区域,还有就是垃圾回收器的基础。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档