现在的位置: 首页 > 综合 > 正文

Heapdump分析过程

2013年03月29日 ⁄ 综合 ⁄ 共 2883字 ⁄ 字号 评论关闭

 

HeapAnalyzer/HeapRoots是一款针对IBM JDK的内存文本镜像HeapDump的分析工具

„      特性:

         离线分析,不影响生产系统

         需要得到IBM JDK内存镜像

         只支持IBM JDK

         HeapRoots字符界面,HeapAnalyzerHeapRoots的图形界面

„      启动方式:

         Kill -3 <pid>得到heapdump文件

         启动HeapAnalyzer或者HeapRoots,加载heapdump文件

         图形化分析

„      HeapDumpIBM JDK Heap内存的一个文本镜像,默认生成位置在Weblogic Server启动目录下,通常是Domain目录

„      如果得不到HeapDump,可能是禁止生成

„      HeapDump的生成开关

         export IBM_HEAPDUMP=true

         export IBM_HEAP_DUMP=true

         export IBM_HEAPDUMP_OUTOFMEMORY=true

         export IBM_JAVADUMP_OUTOFMEMORY=true

         export IBM_JAVACORE_OUTOFMEMORY=true

         export IBM_HEAPDUMPDIR=<directory_path>

„      注意:

         通常HeapDump会比较大,尤其是在Heap内存设置很大的情况下

         为了重现问题,得到现场数据,建议先把HeapDump调小,推荐1G以下

         Window上,如果HeapDump大于1G,可能会无法打开,出现OOM错误

         启动HeapAnalyzer需要指定-Xmx参数

„      启动界面

 

 

 

 

 

       

 

„      内存按树状引用关系显示

 

„      内存按对象和类型显示

 

 

   

„      找到怀疑泄漏的内存对象

 

 

 

预防出现OOM,需要注意的地方:

 

„      系统管理

         足够的物理内存,设置适当的Swap区大小

         最佳的HEAP内存设置

         使用最新的操作系统/最新的JDK/最新版本的WLS

         使用Weblogic Server认证的JDK

         尽量少使用第三方本地代码,或使用Java替代方案

         根据应用设置适当的HttpSession Timeout时间

         根据应用设置适当的EJB Pool/Cache

„      代码编写

         不要放置大量对象到Session

         不要缓存太多数据

         用完的资源一定要close(),例如IOFileJDBC连接

         合理的从数据库取得适量数据

         XML解析对大内存的需求

         统计和报表业务的负荷问题

 

 

下面结合实例来进行讲解:

 

解决建议:

 

1) IBM JDK 1.4及以前版本:-Xms最好是-Xmx的一半对于SUNHPJDK,默认采用的是分代复制垃圾收集策略,建议将最大和最小值设成一样大小。IBM 1.5 版本的JDK开始,也支持分代复制垃圾收集策略,选择该策略时,也建议将最大和最小值设成一样大小。

2) 程序能否直接在后台转换好文件根式,前台只负责下载,能较少资源占用。

3) 前台数据量还要控制。因为报表在weblogic实现确实需要足够支撑力来支持,目前没有办法,bea都不建议用weblogic来统计报表,不过目前也没办法了,WEB是趋势,框架不能改只能来优化。

 报表异步程序内存溢出讲下dump文件看到的一些现象以及分析过程:

   看了下内存异常的javacore 文件我们可以看到core文件中的程序以下部分,在做数据转换,以及显示异步数据结果(如图一): 那这个程序是怎么导致内存溢出的呢,我们可以通过图二看到Monitor监控到有heap lock导致了内存溢出,heap锁,heap分配不足,导致内存溢出,目前看了设置已经调整到

-Xms1024m -Xmx2048m  ,看来内存分配也不能解决太大问题了,32位jdk 已经到极致,除非升级到jdk1.5+weblogic9,不过这个目前不考虑了。

 

既然看到了内存不足,是什么在占用这么多内存资源呢?我们来看图:

 

 

 

 

 

 

 

 

可以看到占用了内存86%的资源,除了系统资源占用外,都被他所消耗,那还怎么干活,资源都光了。可以看到图三中这些都是一些arrayLIst 数组列表,这些一共有多少个呢?看图三右侧图可以看到多少,已经很多了

 

 

 

 

 

可以看到占用了内存86%的资源,除了系统资源占用外,都被他所消耗,那还怎么干活,资源都光了。可以看到图三中这些都是一些arrayLIst 数组列表,这些一共有多少个呢?看图三右侧图可以看到多少,已经很多了

 

at com.asiainfo.openboss.crm.cq.PublicAction$TransLineToRow.TransData(PublicAction.java(Compiled Code))

at com.asiainfo.openboss.crm.cq.PublicAction$TransLineToRow.doTranfer(PublicAction.java:215)

at com.asiainfo.openboss.crm.cq.PublicAction.StyleTransfer(PublicAction.java:2193)

at com.asiainfo.openboss.crm.cq.PublicAction.ListToRowShow(PublicAction.java:2146)

at com.asiainfo.openboss.crm.cq.PublicAction.ShowByRptOut(PublicAction.java:2091)

at com.asiainfo.openboss.crm.cq.PublicAction.UpdateData(PublicAction.java:2000)

at com.asiainfo.openboss.crm.cq.PublicAction.showAsynSonbrQueryResult(PublicAction.java:1232)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) 

 

 到这里应该就可以看到了应用的地方了,所以就请研发立刻进行代码优化吧。

抱歉!评论已关闭.