日期:2011-11-15 15:36:00 来源:本站整理
记一次内存泄露问题的排查阅历[网络技术]
本文“记一次内存泄露问题的排查阅历[网络技术]”是由七道奇为您精心收集,来源于网络转载,文章版权归文章作者所有,本站不对其观点以及内容做任何评价,请读者自行判断,以下是其具体内容:
系统对外供应的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)翻开堆转储文件举行解析
普通我们城市采取下面的“三步曲”来解析内存泄露问题:
首先,对问题发生时刻的系统内存状况获得一个整体印象.
第二步,找到最有大概招致内存泄露的元凶,普通也就是损耗内存最多的对象
接下来,进一步去查看这个内存损耗大户的具体情形,看看能否有什么非常的行为.
以上是“记一次内存泄露问题的排查阅历[网络技术]”的内容,如果你对以上该文章内容感兴趣,你可以看看七道奇为您推荐以下文章:
本文地址: | 与您的QQ/BBS好友分享! |
评论内容只代表网友观点,与本站立场无关!
评论摘要(共 0 条,得分 0 分,平均 0 分)
查看完整评论