调查垃圾回收周期的原因答案

【问题标题】：Investigating Garbage collection cycle causes调查垃圾回收周期的原因
【发布时间】：2014-01-30 19:34:34
【问题描述】：

在当前在生产中运行的基于 BPM 的应用程序（部署在 JBOSS AS 4.2.3 中）中，注意到了一些性能问题，这是因为在峰值负载期间运行的 GC 暂停周期更长。对其进行更多分析，我发现运行 JVM 实例的 jstat 实用程序的以下输出。

/usr/jdk1.6.0-x64/bin/jstat -gccapacity 5583 NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC PGCMN PGCMX PGC PC YGC FGC 838848.0 1677696.0 1677696.0 167744.0 167744.0 1342208.0 3355456.0 6710912.0 6710912.0 6710912.0 21248.0 524288.0 48084.0 48>208 480084.0 4826

/usr/jdk1.6.0-x64/bin/jstat -gcutil 5583 1s S0 S1 E O P YGC YGCT FGC FGCT GCT 0.00 46.33 23.11 81.23 60.38 8451 1386.335 268 159.553 1545.887 0.00 46.33 27.99 81.23 60.38 8451 1386.335 268 159.553 1545.887

在第一个命令中，（使用选项 -gccapacity）我观察到 NGC = NGCMX 和 OGC = OGCMX。这意味着，当前的旧发电容量达到最大旧发电容量，而当前新发电容量达到最大新发电容量。

我想了解一下，这可能是导致频繁执行 GC 循环并执行一些大型执行（有时需要超过 25-30 秒）的原因吗？

对于当前的解决方案，我们已将最大 JVM 堆内存从 8 GB 增加到 9 GB。但是，我们需要了解可能的原因，以便我们可以向开发团队提出同样的问题以优化应用程序。

【问题讨论】：

标签： java performance garbage-collection jvm jvm-hotspot

【解决方案1】：

如果您想了解内存使用的原因，我建议您使用内存分析器。一种选择是使用 VisualVM，但是像 YourKit 这样的商业分析器可能会更好地处理更大的内存大小。

从 8 GB 增加到 9 GB 不会有太大的不同。如果您有内存，请尝试 16 GB 或 30 GB，看看这是否超过了您的需要，然后减少它。

如果您无法在生产环境中分析您的应用程序并且测试没有重现相同的行为，您可以使用jmap -histo 了解最大的内存消耗者。有时这会给你一个线索。

【讨论】：

+1 JVisualVM 很好。还有一个用于远程分析的功能。使用分析器，您可能能够找到应用程序内部的泄漏。
分析器可以帮助您找出为什么您在负载下保留的内存比您认为应该的多。
感谢彼得的回答。我将尝试 jmap -histo 以深入了解原因，并查看是否可以按照您的建议使用任何工具。但是，我想了解 NGC = NGCMX 和 OGC = OGCMX （如我目前的情况），这是一个值得关注的问题并且增加内存，可能会使 NGC 和 OGC 分别低于 NGCMX 和 OGCMX 值吗？注意：我通过执行 jstat -gccapacity . 获得了这些值
除非您有内存泄漏，否则将最大值增加到足够大将导致最大值高于使用的值。

【解决方案2】：

如果您关心的是 GC，也许您可以尝试使用另一种 GC 算法，或者甚至是两者的组合。您描述的场景看起来确实像 GC 算法不能满足您的需求。

Parallel Collector 算法（您可以使用 -XX:+UseParallelGC 启用此功能）可以并行运行次要收集。警告：此算法是“stop-the-world”算法，但可以使用多个处理器来执行 GC。

还有 -XX:+UseParallelOldGC，可以为旧 GEN 启用收集器。

这些算法从一个虚拟机变为另一个。因此，请查看您使用的是哪个版本的 JVM，并尝试选择适合您需求的算法。

正如彼得在回答中所说，分析器将帮助您评估您的应用程序、选择的 GC 算法并做出决定。

【讨论】：

非常感谢您的回答，看看这是否可以解决现有问题。