10

在少数情况下，我们的应用程序使用了大约 12 GB 的内存。我们尝试使用 jmap 实用程序获取堆转储。由于应用程序正在使用一些 GB 的内存，它会导致应用程序停止响应并导致生产出现问题。

在我们的例子中，堆使用量在 6 小时内突然从 2-3 GB 增加到 12 GB。为了找出内存使用趋势，我们尝试在重新启动应用程序后每隔一小时收集一次堆转储。但正如所说，由于使用 jmap 会导致应用程序挂起，我们需要重新启动它，并且我们无法获得内存使用的趋势。

有没有办法在不挂起应用程序的情况下获取堆转储，或者是否有除 jmap 之外的实用程序来收集堆转储。

对此的想法受到高度赞赏，因为如果不了解内存使用的趋势，就很难解决这个问题。

注意：我们的应用程序在 CentOS 中运行。

谢谢，阿伦

4

5 回答 5

11

试试下面的。它带有 JDK >= 7：

/usr/lib/jvm/jdk-YOUR-VERSION/bin/jcmd PID GC.heap_dump FILE-PATH-TO-SAVE

例子：

/usr/lib/jvm/jdk1.8.0_91/bin/jcmd 25092 GC.heap_dump /opt/hd/3-19.11-jcmd.hprof

这个转储过程比用 jmap 转储快得多！转储文件要小得多，但足以让您了解泄漏的位置。

在撰写此答案时，内存分析器和 IBM HeapAnalyzer 存在错误，它们无法从 jmap（jdk8、大文件）读取转储文件。您可以使用 Yourkit 来读取这些文件。

于 2016-11-19T11:56:36.277 回答
2

首先，在拍摄线程转储/快照时冻结 JVM 是（AFAIK）必不可少的。如果 JVM 在创建快照时能够继续运行，那么几乎不可能获得一致的快照。

那么还有其他方法可以获得堆转储吗？

但是所有这些都必然会导致JVM（至少）暂停。

如果您的应用程序实际上挂起（永久！），这听起来像是您的应用程序本身的问题。我的建议是在查找存储泄漏之前先查看是否可以找到该问题。

我的另一个建议是您查看单个堆转储，并使用统计信息来确定哪些类型的对象正在使用所有空间......以及为什么它们可以访问。您很有可能根本不需要“趋势”信息。

于 2013-12-30T05:03:56.833 回答
2

您可以使用 GDB 获取堆转储，而无需在目标 VM 上运行 jmap，但这仍会在将堆转储写入磁盘所需的时间内挂起应用程序。假设磁盘速度为 100MB/s（基本的镜像阵列或单个磁盘），这仍然是 2 分钟的停机时间。 http://blogs.atlassian.com/2013/03/so-you-want-your-jvms-heap/

避免停止 JVM 的唯一真正方法是事务内存和利用它提供进程快照功能的内核。这是 STM 支持者的梦想之一，但目前尚不可用。VMWare 的热迁移很接近，但取决于您的分配率不超过网络带宽并且它不保存快照。请他们为您添加它，这将是一个简洁的功能。

于 2015-03-11T10:43:33.613 回答
1

使用正确工具分析的堆转储将准确告诉您正在消耗堆的内容。它是追踪内存泄漏的最佳工具。但是，收集堆转储很慢，更不用说分析它了。

了解应用程序的工作原理后，有时直方图就足以让您知道在哪里寻找问题。例如，如果MyClass$Inner位于直方图的顶部并且MyClass$Inner仅在 中使用MyClass，那么您确切知道要查找哪个文件来查找问题。

这是收集直方图的命令。

jcmdPIDGC.class_histogram filename=histogram.txt

于 2019-02-06T21:49:45.843 回答
0

要添加到斯蒂芬的答案，您还可以通过 API 为最常见的 JVM 实现触发堆转储：

于 2014-05-18T08:54:01.760 回答