一次内存泄露问题的排查.docxVIP

一次内存泄露问题的排查系统对外提供的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）打开堆转储文件进行分析通常我们都会采用下面的“三步曲”来分析内存泄露问题：首先，对问题发生时刻的系统内存状态获取一个整体印象。第二步，找到最有可能导致内存泄露的元凶，通常也就是消耗内存最多的对象?接下来，进一步去查看这个内存消耗大户的具体情况，看看是否有什么异常的行为。下面将用一个基本的例子来展示如何采用“三步曲”来查看生产的分析报告。??如上图所示，在报告上最醒目的就是一张简洁明了的饼图，从图