性能文章>HeapDump性能社区Young GC异常问题排查实战案例精选合集>

HeapDump性能社区Young GC异常问题排查实战案例精选合集原创

https://a.perfma.net/img/3110416
8月前
443704

在高并发下,Java程序的非正常GC带来的影响往往会被进一步放大。不管是「GC频率过快」还是「GC耗时太长」,由于GC期间都存在Stop The World问题,因此很容易导致服务超时,引发性能问题。本期小编为大家筛选了4篇Young GC问题排查文章,帮大家复习YGC的执行原理和问题排查要点。

1.YGC问题排查,又让我涨姿势了!

作者:Rockets

https://heapdump.cn/article/1661497

本文作者分享了一个棘手的Young GC耗时过长的线上案例,首先是收到服务超时告警,发现了YoungGC耗时过长的问题,然后就开始排查。发现问题后的处理堪称教科书般的操作:“按照GC问题的常规排查流程,我们立刻摘掉了一个节点,然后通过以下命令dump了堆内存文件用来保留现场。jmap -dump:format=b,file=heap pid
最后对线上服务做了回滚处理,回滚后服务立马恢复了正常,接下来就是长达1天的问题排查和修复过程。”

经过确认JVM配置——检查代码——对dump的堆内存文件进行分析——分析YGC处理Reference的耗时——再回到长周期对象进行分析,找出了问题所在:每次调用getConfig方法时都会往List中添加元素,并且未做去重处理,然后立即解决了问题。

文末对YGC相关知识点进行了梳理和总结,从新生代的相关知识讲起,带大家复习了YGC的触发时机和执行过程。

本文是一篇理论与实战结合的经典好文,作者不仅分享了自己遇到YGC问题的排查思路,还就此知识点帮大家复习了原理。读者今后遇到类似的问题可以参考快速分析解决。

2.频繁操作本地缓存导致YGC耗时过长

作者:阿菜

https://heapdump.cn/article/1578279

本文作者在帮群友排查YGC耗时过长问题,通过分析堆栈和GC log发现,在某次YGC时,Survivor区中年龄超过7的对象占用了Survivor空间一半以上。而正常情况下,年轻代对象朝生夕死。网络服务处理请求为毫秒级,YGC几秒甚至十几秒才发生一次,多数年轻对象活不过1代。于是,猜测该群友使用了本地缓存。进一步沟通后得出结论:原因一:年轻代中有太多存活的对象,增加了标记时间;原因二:YGC又需要花费大量的时间在扫描Card Table上,总结原因是操作本地缓存太频繁导致了YGC耗时过长。最后向群友提出了修改意见解决了问题。

在文章结尾作者还总结了该业务场景的几条修改建议,很有参考价值。

3.我司基础组件更新本地缓存策略问题导致young gc时间升高

作者:朱纪兵

https://heapdump.cn/article/1910972

本文作者在一次研究服务QPS和young gc的时间的关系时,发现实际情况与理想状态不同,于是开始追踪问题。用gdb 去dump了下来survivor区域中的内容,发现了异常点。最后发现是公司配置中心基础组件更新本地缓存策略的问题。

作者遇到问题不忽视主动排查反复验证的精神值得学习。

4.耗时20多秒的young gc,你见过吗?

作者:Edenbaby

https://heapdump.cn/article/1907474

作者遇到了耗时20多秒的young gc,在排查时发现user(用户耗时)+sys(系统耗时) <real(真实耗时),但大多数的young GC中,real time是小于sys+user time的,因为paralle垃圾回收器是多线程并发的去GC,所以user time是各个线程累积的一个时间,大概率要大于real time。因此猜测是CPU不够用或磁盘IO压力大导致的。
排查YGC异常问题,一定要掌握GC执行过程,会看GC log,从日志中找到突破点。

请先登录,再评论

暂无回复,快来写下第一个回复吧~

为你推荐

不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
JVM实战:优化我的IDEA GC
IDEA是个好东西,可以说是地球上最好的Java开发工具,但是偶尔也会卡顿,仔细想想IDEA也是Java开发的,会不会和GC有关,于是就有了接下来对IDEA的GC进行调优 IDEA默认JVM参数: -
字符串字面量长度是有限制的
前言 偶然在一次单元测试中写了一个非常长的字符串字面量。 正文 在一次单元测试中,我写了一个很长的字符串字面量,大概10万个字符左右,编译时,编译器给出了异常告警 `java: constant
多次字符串相加一定要用StringBuilder而不用-吗?
今天在写一个读取Java class File并进行分析的Demo时,偶然发现了下面这个场景(基于oracle jdk 1.8.0_144): ``` package test; public c
如何通过反射获得方法的真实参数名(以及扩展研究)
前段时间,在做一个小的工程时,遇到了需要通过反射获得方法真实参数名的场景,在这里我遇到了一些小小的问题,后来在部门老大的指导下,我解决了这个问题。通过解决这个问题,附带着我了解到了很多新的知识,我觉得
JVM源码分析之String.intern()导致的YGC不断变长
概述之所以想写这篇文章,是因为YGC过程对我们来说太过于黑盒,如果对YGC过程不是很熟悉,这类问题基本很难定位,我们就算开了GC日志,也最多能看到类似下面的日志`[GC (Allocation Fai