heapdump文件太大无法分析怎么办

v

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

„ 特性：

– 离线分析，不影响生产系统

– 需要得到IBM JDK内存镜像

– 只支持IBM JDK

– HeapRoots字符界面，HeapAnalyzer是HeapRoots的图形界面

„ 启动方式：

– Kill -3 <pid>得到heapdump文件态宏

– 启动HeapAnalyzer或者HeapRoots，加载heapdump文件

– 图形化分析

„ HeapDump是IBM 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()，例如IO，File，JDBC连接

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

– XML解析对大内存的需求

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

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

解决建议：

1) IBM JDK 1.4及以前版本：-Xms最好是-Xmx的一半对于SUN和HP的JDK，默认采用的是分代复制垃圾收集策略，建议将最大和最小值设成一样大小。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)

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

�故荖ative thread无法创建，前者用MaxPermSize调整（IBM JDK没这个参数），后者调小最大堆大小或者Xss调整每个线程分配内存的大小。如果是常见的堆的溢出，确保OutOfMemory时能生成heapdump文件，用Dump analyzer或者MDD4J分析dump文件，找到堆中占用空间总数差春最大的（或者数量最多的）对象。然后调整堆范围到一个比较小的区间，比如256M～384M，重新启动服务器，在运行1小时候手动做一次heapdump，运行4小时后做一次heapdump，运行8小时候做一次（间隔仅作参考）。然后分析一下三者的区别，看看哪个对象数量增长很多，占用空间增加很大。结合OutOfMemory时候的分析，应该能锁定问题的源头。 huweihong: 内存溢出是使用WAS时会经常遇到的问题。1.现在WAS的控制台上打开详细垃圾回收。一旦出现OOM的错误时，会在nativeerr.log中有记录，也可以从这个日志中看出内存分配的情况。2。参见hashei的者冲回帖把相关日志收集齐，使用ISA中的相关工具进行日志分析，会看到一些提示的。有的时候内存溢出是WAS自身引入的，可以看看是不是有相关的补丁包。还有多数都是自己开发程序的问题，使用的对象没有释放。这个就要具体情况具体分析了。其实解决所有的问题的思路就是：大胆假设，小心求证。我的经验。：） 呵呵，其实我感觉95%以上的OOM发生都是和代码本身的质量有关系的，以下是我的一点小思路,不知道对大家是否有帮助:OOM的情况,必定会产生宕机日志,所以,首先从分析宕机日志开始.分析工具很多,根据侧重点不同进行选取即可.一般情况下无非就是两重情况:大对象和内存泄露.于是,赶紧查查业务代码,是那些地方产生的.一个好的框架会帮你节省不少首庆歼体力活的.不过我感觉一般的大对象大都是RS引起的,不小心查了几万行数据又不做分页,不宕机都不行啊。

浏览Heap Dump

可以使用VisualVM浏览heap dump文件的内容，从而快速查看在堆中分配的对象。Heap dumps在主窗口的heap dump子标签页中显示。你可以打开保存在本地的heap dump文件（.hprof）或者使用VisualVM捕获正在运行的程序的heap dumps。

一个heap dump是Java虚拟机（JVM）在某一时刻所有对象的快照。JVM从堆中为所有的类实例和数组分芹枝胡配内存。当一个对象不再被使用并且没有对它的引用时，垃圾回收器回收其堆内存。通过查看堆，你可以找到对象创建的位置，发现对象的引用。如果JVM试图从堆中移除不再需要的对象时失败了，VisualVM可以定位到离该对象最近的垃圾回收根（garbage collecting root）。

打开Heap Dump文件

如果你有一个保存在本地的heap dump文件，在VisualVM中通过File >Load菜单项加载该文件。VisualVM能打开.hprof格式的heap dumps文件。打开后，heap dump作为主窗口的一个子标签页。

捕获Heap Dump

可以使用VisualVM捕获一个本地运行的应用程序的heap dump。捕获的heap dump文件是一个临时文件，关闭VisualVM后自动删除，若要保留，需要将其另存嫌拦为文件。

可通过以下两种方法捕获heap dump：

在左侧“Application”（应用程序）子窗口中右击相应的应用程序，选择Heap Dump（堆Dump）。

在Monitor（监视）子标签页中点击Heap Dump（堆Dump）按钮。

本地应用程序的Heap dumps作为应用程序标签页的一个子标签页打开。同时，heap dump在左侧的Application（应用程序）栏中对应一个含有时间戳的节点。右击这个节点选择save as（另存为）即可将heap dump保存到本地。

浏览Heap Dump

VisualVM提供了一下可视化视图来浏览heap dumps：

Summary View（概述）

打开一个heap dump时，VisualVM默认显示“概述”标签页。概述视图显示了该heap dump的捕获环境和其他搭闭系统属性。

---