heapdump分析简单总结

| Comments

  • 详细的材料可以查看IBM的HeapAnalyzer胶片
  • 本文只是自己的一些简单总结(废话比较多),重点还是大家基于实际dump文件去积累经验
  • 就一个工具,大家都掌握好了就可以有更多时间研究其他东西。

heapdump是什么

  • 通常的名字类似heapdump.20150919.162323.43385076.0055.phd,参考ppt的第12页
  • java堆内存快照(不包括jni,不是c/c++通常说的那个堆)
  • 用来分析oom的原因

heapdump如何生成

  • 参考ppt的第8~12页,通常维护/CMO都知道
  • 需要注意的是,大型中间件的dump是挺大的,需要有足够的硬盘空间,否则频繁的dump会导致空间不足引发其他问题。(频繁dump在生产上是可能的事情)

heapdump分析用什么工具

  • 使用IBM HeapAnalyzer(目前最新ha456.jar, 比之前的版本有更多视图,性能更好)
  • 启动方式: java -jar -Xms512m -Xmx3g ha456.jar
  • 通常要文件大小5倍+的内存, 而websphere之类的dump多在500m以上,所以需要64位的大内存机器,用64位的jdk,堆内存开2g以上
  • 工具需要界面,如果大内存64位机器如果只能找到服务器,可以采用远程运行(但受网速影响)。参考”export DISPLAY=192.168.88.71:0.0”设置xmanager的远程界面显示

ha概念要点

  • 本质上是根据对象引用关系生成一个树结构(可以结合gc的原理加深理解),参考ppt的第14页
  • 结合图例说明

图例说明

ha关注要点

  • 关注Leak Suspect,这是检测出来的可能的问题点,有时候非常方便。参考ppt的第34~37页
  • 关注内存占用比例较大的对象,ha支持按TotalSize大小顺序排列(如上图)
  • 关注节点数众多的情况,而且基本上是挂靠在容器上的(不大可能一个对象有n多内部变量),常见的有map,array,list
  • 关注自己的类,com.huawei开头的。ha支持查询,参考ppt的第54~59页。
  • 有多种维度的视图,多摸索,例如Type List就可以根据特定类型的对象数量进行排序,或许可以找到一些小的内存问题。
  • 如果能够拿到javacore,可以进行对比,定位是哪个功能引起的(单靠类名不一定能够识别哪个业务)。

常见的原因

常见的问题原因如下(有交集,并没有严格分类):

  • 内存设置太低,不过这个几率比较小。一般的web应用内存分配2G还不够,调大也不是办法。
  • 大量的线程泄露(或者某种原因阻塞),java的线程是系统线程,占用的资源还是可观的,相关的可以看Xss参数。生产一般看到的websphere也就300左右。
  • 查询/导出大量数据, 常见于SQL查询结果没有限制数量、或者在内存中集中写出。
  • 远程调用传输大量数据,常见于cics返回大量数据(其实和上面差不多是一个道理)
  • 上传并处理数据,没有分批分段处理或延后处理。
  • 数据没能及时释放,可能是处理较多的数据或较长的处理流程,不过需要显式释放对象引用的情况是比较少见的。

不过,需要注意的是:

  • 像dbc这样的jni实现可能和这个没什么关系,原因在于64位机器进程空间很大。
  • 像数据库,远程调用等响应慢,是不一定会出现dump问题的。但它会导致线程数增多(同步),数据(占用内存)未及时处理,从而导致dump。

Comments