一次老生代内存使用占比飙升问题解决

一次老生代内存使用占比飙升问题解决

老生代内存使用占比图示

 

如图所示老生代内存占比不断增加，超过80%系统自动报警，之前的解决方案是手动重启😜。

 

1、保存现场

为了解决上面老生代问题，首先需要dump下堆文件

命令：

ps -ef|grep DialingRobot

 

 DialingRobot是服务名称，找到对应的pid

 

pid：70992

dump堆内存

jmap -dump:format=b,file=1.dump 70992

将堆内存dump下来

为了分析内存的变化，可以在不同的时间进行dump操作，可以分析前后的内存变化，更方便查找问题

2、分析问题

 

 1、jprofiler分析dump文件

将文件重命名为20200520.hprof（.hprof是可以分析的堆文件）

 

 

 打开后长这样

可以去看一下biggest对象

 

 

 

 

 

 

点开之后发现，占有内存比较大是正常的，这些类里面都存放着大量的内存缓存。

 

 

 

第二考虑是不是这个类太多了，没有释放，分析两个时间段的堆内存，两个dump中的这个对象的数量大小差异不大。尝试mat去分析下dump文件。

 2、mat分析dump文件

 

 

 主要使用两个模块：Histogram和LeakSuspects

Histogram主要展示堆内的各个对象的大小

 

 

将两个hprof文件导入mat，可以使用比较去分析两个内存的前后的变化

 

 

 两个hprof文件前后对象的差异、内存的差异

 

 分析这些差异，没有看到什么有用的信息。

尝试使用第二个mat的工具：Leak Suspects

 

 

mat给出两个suspect，可以分析下，第一个还是之前的class文件过大，但是是由于内部维护了一部分缓存造成的，第二个cs csSocket也不是，跟JProfiler差异不大。

 

这个时候分析到达一个比较艰难的时候。

这个时候查看下jvm的参数设置：

 

可以看出来整个堆的大小是：1g，新生代是256mb，老年代是1024-256=768mb，看上去没有什么问题。

这个时候需要分析我们的应用，我们的应用中的对象的特征，我们应用中的对象很少有需要一直存在的对象，更多是朝生夕死的对象，这样的话，这个的是不是有问题呢？

我们去看看新生代的内存、回收情况。

 

可以看出来，老生代内存使用率的增加和新生代的gc强相关，新生代gc一次，老生代的内存使用率升高一点

 

3、解决问题

修改jvm参数

 

 

将堆内存从1g->2g，新生代256m->1024m，观察老生代情况。

 

可以看出来：老生代内存使用占比稳定，新生代回收频率也降低了很多（13 -> 3 /30min），单次耗时：（10ms -> 20ms），30分钟内gc时间从130ms -> 60ms，降低了一倍

 由此可见，服务中存在大量短期临时对象，扩容新生代空间后，Minor GC频率降低，对象在新生代得到充分回收，只有生命周期长的对象才进入老年代。这样老年代增速变慢，Major GC频率自然也会降低。