1

因此，我一直在尝试寻找一种好方法来监控 JVM 何时可能会出现 OOM 情况。他们似乎与我们的应用程序一起工作的最佳方式是通过 CMS 跟踪背靠背并发模式故障。这表明永久池的填充速度超过了它实际清理自身的速度，或者它的回收速度非常慢。

用于跟踪 GC 的 JMX bean 具有非常通用的信息，例如之前/之后的内存使用情况等。这些信息充其量是相对不一致的。有没有更好的方法可以监控这个即将死去的 JVM 的潜在警告信号？

4

2 回答 2

2

假设您使用的是 Sun JVM，那么我知道 2 个选项；

  1. 您似乎已经在使用的内存管理 mxbeans（API 参考从此处开始），但请注意，您可以访问一些特定于热点的内部热点，请参阅此博客以获取有关如何使用的示例
  2. jstat: cmd 参考在这里，你会想要这个-gccause选项。您可以编写一个脚本来启动它并解析输出，或者理论上，您可以从主机 jvm（或另一个）生成一个进程，然后从 jstat 读取输出流以检测 gc 原因。我不认为原因报告是 100% 全面的。我不知道如何从 Java 代码中以编程方式获取此信息。
于 2011-03-29T20:52:28.813 回答
0

使用标准 JRE 1.6 GC，堆利用率可能会随着垃圾收集器的运行频率越来越低，这取决于应用程序的性质和指定的最大堆大小。也就是说，如果没有更多信息，很难说发生了什么。

一些进一步调查的方法：

您可以在使用 jmap 运行应用程序时对其进行堆转储，然后使用 jhat 检查堆以查看在任何给定时间哪些对象在堆中。

您还可以使用 -XX:+HeapDumpOnOutOfMemoryError 运行您的应用程序，这将在 JVM 遇到的第一个内存不足异常时自动进行堆转储。

您可以创建一个特定于您的应用程序的监控 bean，并创建您可以使用远程 JMX 客户端访问的访问器方法。例如，返回队列和其他集合大小的方法，这些集合可能是程序中内存利用的地方。

高温高压

于 2011-03-29T18:45:53.297 回答