CMS老年代增长排查总结
作者:互联网
一般对于内存泄漏导致OOM的,可以通过MAT在OOM时生成的dump中查看老年代贡献最大的对象,定位问题代码。
但对于老年代缓慢增长FGC又能被回收的,排查会相对麻烦,可以按如下方式进行尝试。
1. 添加GC参数,打出对象分布
-XX:+PrintTenuringDistribution
2022-03-31T19:54:17.891+0800: 7446.946: [GC (Allocation Failure) 2022-03-31T19:54:17.892+0800: 7446.946: [ParNew Desired survivor size 751599616 bytes, new threshold 10 (max 10) - age 1: 20029920 bytes, 20029920 total - age 2: 3097184 bytes, 23127104 total - age 3: 4769904 bytes, 27897008 total - age 4: 2000296 bytes, 29897304 total - age 5: 5371680 bytes, 35268984 total - age 6: 732136 bytes, 36001120 total - age 7: 2503944 bytes, 38505064 total - age 8: 1614288 bytes, 40119352 total - age 9: 726808 bytes, 40846160 total - age 10: 1219032 bytes, 42065192 total : 11804946K->61651K(13212096K), 0.1111841 secs] 18153507K->6410815K(25795008K), 0.1119925 secs] [Times: user=1.25 sys=0.01, real=0.11 secs]gc.log
2. 根据"new threshold" 关键词查看是否有提前晋升到老年代的
本case中没有,都是与MaxTenuringThreshold=10相同的, 故没有大对象都是按照常规流程多次YGC后晋升到老年代的。
3. 查看age=10(10为自定义或默认的 MaxTenuringThreshold)中的对象(这些都是即将晋升到老年代的)
可以使用工具 vjmap 查看( https://github.com/vipshop/vjtools/tree/master/vjmap )
./vjmap.sh -sur:age=10 <PID> > /tmp/histo-sur-10_0331_1015.log
4. 定位问题的代码位置
在上述文件中找排在前面的业务代码相关的类,如上述case中的 io.dropwizard.metrics5.WeightedSnapshot$WeightedSample,com.xxx.soa.caravan.ribbon.Server,credis.java.client.pool.impl.CRedisJedis
再在代码中梳理相关逻辑,看看哪里会产生这些对象,评估可能的点。
5. 添加埋点测试验证
标签:总结,10,age,bytes,vjmap,排查,secs,total,CMS 来源: https://www.cnblogs.com/ylz8401/p/16091584.html