当前位置:七道奇文章资讯安全技术网络技术
日期: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 AnalyzerMAT)翻开堆转储文件举行解析

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

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

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

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

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


  以上是“记一次内存泄露问题的排查阅历[网络技术]”的内容,如果你对以上该文章内容感兴趣,你可以看看七道奇为您推荐以下文章:
  • 记一次内存泄露问题的排查阅历
  • 本文地址: 与您的QQ/BBS好友分享!
    • 好的评价 如果您觉得此文章好,就请您
        0%(0)
    • 差的评价 如果您觉得此文章差,就请您
        0%(0)

    文章评论评论内容只代表网友观点,与本站立场无关!

       评论摘要(共 0 条,得分 0 分,平均 0 分) 查看完整评论
    Copyright © 2020-2022 www.xiamiku.com. All Rights Reserved .