19

问题

我们正试图找出我们的 Web 应用程序中出现大内存泄漏的罪魁祸首。我们在查找内存泄漏方面的经验非常有限，但我们发现了如何使用jmapEclipse MAT 进行 Java 堆转储并对其进行分析。

然而，我们的应用程序使用 56/60GB 内存，堆转储的大小只有 16GB，在 Eclipse MAT 中甚至更小。

语境

我们的服务器在 Ubuntu 14.04 上为我们的 java 应用程序使用 Wildfly 8.2.0，其进程使用了​​ 95% 的可用内存。进行转储时，我们的缓冲区/缓存使用空间为 56GB。

我们使用以下命令创建转储：sudo -u {application user} jmap -dump:file=/mnt/heapdump/dump_prd.bin {pid}

堆转储文件大小为 16.4GB，当使用 Eclipse MAT 分析它时，它说大约有 1GB 活动对象和约 14.8GB 不可达/浅堆。

编辑：这是有关我们看到的问题的更多信息。我们监控我们的内存使用情况，我们看到它不断增长，直到剩下大约 300mb 的可用内存。然后它会停留在该内存量附近，直到进程崩溃，不幸的是应用程序日志中没有错误。

这使我们假设这是一个严重的 OOM 错误，因为这只发生在内存接近耗尽时。我们使用-Xms25000m -Xmx40000mJVM 的设置。

问题

基本上，我们想知道为什么我们的大部分内存没有在这个转储中捕获。顶级保留大小类看起来不太可疑，所以我们想知道是否有一些与堆转储相关的东西我们做错了什么。

4

2 回答 2

25

转储其堆时，JVM 将首先运行垃圾回收周期以释放任何无法访问的对象。

如何在不先进行垃圾收集的情况下在 Java 5 上进行堆转储？

根据我的经验，在真正的 OutOfMemoryError 中，您的应用程序只是要求比可用的堆空间更多，这个 GC 是愚蠢的差事，最终的堆转储将是最大值的大小。堆大小。

当堆转储小得多时，这意味着系统并不是真正的内存不足，而是可能有内存压力。例如，有一个java.lang.OutOfMemoryError: GC overhead limit exceeded错误，这意味着 JVM 可能已经能够释放足够的内存来服务一些新的分配请求，但它不得不花费太多时间来收集垃圾。

您也可能没有内存问题。是什么让你觉得你做的？您没有提及有关堆使用或 OutOfMemoryError 的任何内容。您只提到了 JVM 在操作系统上的内存占用。

于 2015-08-28T13:09:34.490 回答
5

根据我的经验，堆转储比实际使用的内存小得多可能是由于 JNI 中的泄漏。

尽管您不直接使用任何本机代码，但某些库使用它来加速。

在我们的例子中，这是一个Deflater和Inflater没有正确结束。

于 2016-11-23T10:20:45.213 回答