记一次内存泄露问题的排查阅历[网络技术]

系统对外供应的Solr查询接口,在来自外部调用的压力加大之后,就会呈现solr查询报Read Timed Out的非常,从表面现象上看是此时solr核压力过大,无法呼应过量的查询恳求.

      但实际上此时并发查询压力并非很大,那么为什么solr核会无法及时呼应查询恳求呢?首先用top查看了下load average,也是很低,也佐证了系统本身压力并不大.

      然后,用jstack –l <pid> 查看那些cpu利用率太高的线程,发现全都是GC线程,阐明GC过于频繁,并且耗时太长,招致利用线程被挂起,无法呼应客户端发来的恳求,这种情形就应当是有存在内存泄露的问题咯.

 于是,就用jmap将进程的堆转储文件dump出来到heap.bin文件中

JMap -dump:format=b,file=/tmp/heap.bin <pid>

然后用Eclipse Memory Analyzer（MAT）翻开堆转储文件举行解析

普通我们城市采取下面的“三步曲”来解析内存泄露问题:

首先,对问题发生时刻的系统内存状况获得一个整体印象.

第二步,找到最有大概招致内存泄露的元凶,普通也就是损耗内存最多的对象

    接下来,进一步去查看这个内存损耗大户的具体情形,看看能否有什么非常的行为.

[1] [2] [3] [4]  下一页