问题标签 [heap-dump]

在过去的几天里，我们看到我们服务器上的 JVM 进入了一种状态，即它们在 OldGen 的 GC 中花费了 100% 的 CPU 时间，此时：

A. 他们不需要，因为堆上有足够的空间，并且

B. 他们没有回收任何东西。

通过查看堆栈跟踪并将 ProcessExplorer 中的 ThreadID 与堆栈转储中的相关联，我知道它们在 GC 中。每个 GC 线程占用大约 4% 的 CPU。

服务器运行 16 gig 堆（32gig 物理 RAM）并有 8 个内核。正常运行时间通常约为 30 天，仅由于 MS 补丁要求而需要重新启动，但目前它们在 20 天时崩溃。

这是持续时间的图表，时间尺度 = 19 天。 http://i45.tinypic.com/257qalu.png

这是该图尾部的放大图 http://i48.tinypic.com/2duiccw.png

如您所见，持续时间急剧增加。

这是 GC 后堆使用情况的图表。 http://i48.tinypic.com/znna4h.png

如果这是一个典型的内存泄漏，我希望看到橙色的峰值越来越高，直到它们不再达到峰值，但正如这张图所示，还有大量的堆空间。

我为每台服务器都有堆转储，没有什么特别突出的问题。有几个ehCache存储，我可以看到我们的应用程序代码，即，只是“普通的东西”

我们大约 20 天前所做的最大改变是实现了一个供应商补丁，该补丁将内部缓存从使用硬引用（以及明显的内存泄漏）的无界哈希映射更改为由软引用组成的缓存，我想知道这是否是原因，即，在某个点之后管理这些软引用会产生巨大的开销？

有没有人对下一步看哪里有任何想法，或者有人可以证实我的软参考理论吗？

这是我的 jvm.args：

java.args=-server -Xms16000m -Xmx16000m -Dsun.io.useCanonCaches=false -XX:MaxPermSize=350m -Xloggc:e:/gcLogs/eRGCLogs.txt -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps - XX:+PrintGCDateStamps -XX:+UseParallelGC -XX:+UseParallelOldGC -Dnet.sf.ehcache.sizeof.filter=D:/jo3/java_ehCacheOpenSource/sizeOfExclusions.config -Xbatch -Dcoldfusion.rootDir={application.home}/.. / -Dcoldfusion.libPath={application.home}/../lib -Dcoldfusion.classPath={application.home}/../lib/updates,{application.home}/../lib,{application.home} /../gateway/lib/,{application.home}/../wwwroot/WEB-INF/flex/jars,{application.home}/../wwwroot/WEB-INF/cfform/jars,d:/ jo3/java,d:/JO3/java_ehCacheOpenSource/,D:/jo3/java_ehCacheMonitorProbe

我们在 Coldfusion 上，它有点像一个位于 java 之上的大型框架。

JVM版本：1.6.0_29

根据要求，“正常”GC 日志如下所示：

2013-03-19T22:11:36.670+1100: 1288665.702: [GC [PSYoungGen: 4695800K->471119K(4722112K)] 9301727K->5077046K(15644800K), 0.3584434 秒=0.3584434 秒=0 时间。 0.36秒] 2013-03-19T22：14：55.078 + 1100：128864.099：[GC [PSYOUNGGEN：4722063K-> 498009K（4783104K）9327990K-> 5103936K（15705792K），0.3766889秒，0.3766889秒] [次数：user = 5.37 sys = 0.00 , real=0.38 秒] 2013-03-19T22:17:46.749+1100: 1289035.760: [GC [PSYoungGen: 4654489K->517299K(4673792K)] 9260416K->5123227K(155930580K), 0.s [时间 1:40580K), 0. sys=0.00, real=0.41 secs] 2013-03-19T22:21:08.762+1100: 1289237.763: [GC [PSYoungGen: 4673779K->522660K(4738880K)] 9279707K->5143831K(156605516K s) [043831K->5143831K(156605516K s) 0.Time用户=5.97 系统=0.00，实际=0.40 秒] 2013-03-19T22:23:42.683+1100:1289391.675:[GC [PSYoungGen:4582628K->530998K(4590976K)] 9203799K->5186242K(15513664K), 0.4317352 秒] [时间: 用户=6.24 系统=0.00, 实际=0.43 秒] 2013-03-19T22:26:11.096+1100: [GCPSYoungGen5.90: 128 4590966K->518331K(4724096K)] 9246210K->5206959K(15646784K)，0.3914401 秒] [时间：用户=5.99 系统=0.00，实际=0.39 秒] 2013-03-19T22:257:44.0763:3. [GC] [PSYOUNGGEN：2602730K-> 447527K（4732864K）] 7291358K-> 5208743K（15655552K），0.3725317秒，0.3725317秒] [次数：User = 5.80 Sys = 0.00，Real = 0.37秒] 2013-03-19T22：27：4448 + 1100：1289633.428 ：[全GC（系统）[PSYOUNGGEN：447527K-> 0K（4732864K）] [PARORDGEN：4761215K-> 4628296K - > 4628296K（15655552K）[PSPermgen：352378K-> 352287K（352832K），4.2955639秒] [时间：用户 = 57.70 系统 = 0.06，实际 = 4.30 秒] 2013-03-19T22：30：37.950+1100：1289806.920：[GC [PSYoungGen：4004416K->70948K(4690432K)] 8632712K->4699245K(15613120K), 0.1062227 secs] [Times: user=0.76 sys=0.00, real=0.11 secs] 2013-03-19T22:33:27.154+1100: [12GC861599] 4054116K->109175K(4092352K)] 8682413K->4737472K(15015040K), 0.1347919 秒] [时间: 用户=1.03 系统=0.00, 实际=0.13 秒] 2013-03-19T22:306: [32.9016+] [PSYoungGen: 4092343K->147318K(4712320K)] 8720640K->4775615K(15635008K), 0.1593523 secs] [Times: user=1.58 sys=0.00, real=0.16 secs] 24092343K->147318K(4712320K)] 8720640K->4775615K(15635008K)，0.1593523 秒] [时间：用户=1.58 系统=0.00，实际=0.16 秒] 24092343K->147318K(4712320K)] 8720640K->4775615K(15635008K)，0.1593523 秒] [时间：用户=1.58 系统=0.00，实际=0.16 秒] 2

当我们处于故障模式时，GC 日志如下所示：

2013-03-22T10:03:47.619+1100: 1504185.901: [GC [PSYoungGen: 0K->0K(5452736K)] 4413907K->4413907K(16375424K), 0.0114248 秒] [时间: 用户=0.16 系统= 0.01 秒] 2013-03-22T10:03:47.631+1100: 1504185.912: [完整 GC [PSYoungGen: 0K->0K(5452736K)] [ParOldGen: 4413907K->4412613K(10922688K)] 44133901->44133K017664426 PSPermGen: 358399K->358278K(358400K)], 5.4435442 秒] [时间: 用户=73.74 系统=0.14, 真实=5.44 秒] 2013-03-22T10:03:53.145+1100: 1504191.26926: [GCK-PSYoungGen: >7734K(5449088K)] 4681833K->4422114K(16371776K), 0.0298728 secs] [Times: user=0.34 sys=0.00, real=0.03 secs] 2013-03-22T10:03:53.175+1100: [Full 1.456: 15041: PSYoungGen: 7734K->0K(5449088K)] [ParOldGen: 4414379K->4415189K(10922688K)] 4422114K->4415189K(16371776K) [PSPermGen: 358399K->358371K(358400K).,6033684 秒] [时间：用户=36.33 系统=0.00，实际=2.60 秒] 2013-03-22T10:03:55.788+1100: 1504194.069: [GC [PSYoungGen: 94969K->826K(5451328K)] 4410101K58K->446101K58K->4 16374016K），0.0133588 秒] [时间：用户 = 0.16 系统 = 0.00，实际 = 0.01 秒] 2013-03-22T10：03：55.802+1100：1504194.082：[完整 GC [PSYoungGen：826K->0K（5451328K）] ParOldGen: 4415189K->4415348K(10922688K)] 4416015K->4415348K(16374016K) [PSPermGen: 358399K->358389K(358400K)], 2.7156884 secs] [Times: user=38.171 sys=0002,=2.71 系统4415189K->4415348K(10922688K)] 4416015K->4415348K(16374016K) [PSPermGen: 358399K->358389K(358400K)], 2.7156884 secs] [Times: user=38.11 sys=0.0.0.04415189K->4415348K(10922688K)] 4416015K->4415348K(16374016K) [PSPermGen: 358399K->358389K(358400K)], 2.7156884 secs] [Times: user=38.11 sys=0.0.0.0

我正在尝试分析尝试为使用接近 3 GB 堆内存的应用程序进行堆转储对性能的影响。这是为了决定和理解我是否应该启用将堆转储作为一种主动而不是最后的被动措施来监控内存泄漏的可能性。以前有没有人研究过这样的事情。是这样吗，请你帮帮我。提前致谢。

我正在尝试控制我的堆转储在哪里使用内存异常-XX:HeapDumpPath

我的 java 进程没有写入当前工作目录的权限，所以我试图指定user.home目录。我无法提前知道绝对名称，所以我尝试使用变量来做到这一点user.home

我试过-XX:HeapDumpPath=${user.home}/mydump.hprof了，但这不起作用

是否有可能做到这一点？

当尝试使用 jmap 将 java 核心转储转换为 hprof 时，我得到了这个执行：

我使用了命令：

对此有什么帮助吗？

我正在尝试在同一个盒子中创建 hprof，在那里我得到了核心转储。

在 outofmemoryerror 上没有得到 java 堆转储：试过这个（one.exe 是我的 java rcp 应用程序）：

但没有帮助，文件夹路径是可访问的。我什至尝试给出 heap.hprof 之类的名称，但没有结果。有人可以在这里指导我吗？

我正在尝试在使用 open-jdk7 java 运行 glassfish 3.1.2 的机器上生成堆转储。

我正在使用以下命令：

但我不断收到此错误：

这是我的完整 Java 版本：

确切的 CentOS 版本是：

有任何想法吗？

我们工作中的测试人员无法通过手动测试使我们的应用程序出现 OOM 错误，但是当我们运行集成测试时，在大约 50 次左右的测试之后，我们得到了 OOM 错误，并且其余的测试都没有完成。

当我们在集成测试期间获得 OOM 时，我想转储堆。我正在使用 Maven 和 Spoon 来启动集成测试。我真的很想看看堆，看看是什么杀死了内存。我在测试运行期间尝试连接监视器，但 ddms 尝试连接的端口被绑定。

我试图调查java.lang.OutOfMemoryError: GC limit exceeded在我们部署在 tomcat 中的 web 应用程序的高负载时发生的情况。堆大小设置为 8GB ( -Xms2048m -Xmx8192m)

在某个时间点，由于 GC 活动开销，我们的应用程序变得无响应。我可以在日志中看到 Full GC 连续发生多次。所以我使用以下命令（jmap -F -dump:format=b,file=/root/dump2.hprof 4963）进行了堆转储。包含转储的文件大小为 9GB。进行转储后（应用程序被冻结了大约 45 分钟），发生了多次完整的 GC，直到OutOfMemoryError被抛出。

这是 GC 活动的日志示例

为了分析堆转储，我在 Eclipse 内存分析器 (MAT) 中打开了它。不幸的是，MAT 显示堆大小为 363.2MB（在概览选项卡或堆转储详细信息选项卡中），而根据 GC 日志，堆已填满 6467961K (6.4G)。Unreachable Objects Histogram 总共显示 75 511 736 (75 MB)。直方图视图也证实了浅堆的总数为 380 837 136 (363.2MB)

我的问题是，如果 GC 无法回收内存，为什么 MAT 不显示堆转储中的所有对象？

以下是 MAT 中导入的堆转储的屏幕截图：

• 概述
• 无法到达

我正在尝试从我的 java 程序中生成一个堆转储，但无论我尝试什么，我似乎都无法弄清楚如何去做。

我下载了 Eclipse 内存分析器（插件然后是独立的），它应该能够从活动的 jre 进程中获取热转储。但它没有列出任何内容。文档列出了其他几种生成它们的方法，但我似乎无法使它们中的任何一个起作用，或者它们引用了我的系统上似乎不存在的东西。这同样适用于我在网上找到的任何东西......

该程序不会导致内存不足异常，它只是使用了比我预期的更多的资源。

我完全不知道它应该如何完成：/

任何帮助将不胜感激。

我运行了一个 jvm 进程，有一天它遇到了内存不足的异常。在日志中我发现了许多内存不足的错误::

<1372410567863>

它还生成了一个heapdump文件，我用mat分析后发现它是一个线程中的一个大对象，我只知道它是一个hibernate common object org.hibernate.engine.PersistenceContext，但我不知道它来自哪里。

我想写一个小程序，当出现内存不足错误时，它会自动生成一个threaddump文件。

我的问题是：程序执行的最佳时间是准确地进行线程转储？是在日志文件中出现的第一个内存不足错误吗？