主要垃圾回收原因故障排除答案

【问题标题】：Troubleshooting Major Garbage Collection Cause主要垃圾回收原因故障排除
【发布时间】：2017-09-17 17:34:22
【问题描述】：

我有一个在 Open SDK 1.7.0_95 64 bin 环境上运行的 Java 应用程序，我看到每小时有两次主要的垃圾收集，这会影响应用程序的响应时间，我打算避免它。截至目前，使用 your-kit profile 分析我的应用程序。任何人都可以帮助我解决这些主要 GC 的原因的步骤，以便我可以尽可能避免它。应用程序部署在 Linux 环境下的 Jboss EAP 6.2 上。

OpenJDK 运行时环境 (rhel-2.6.4.0.el6_7-x86_64 u95-b00) OpenJDK 64 位服务器 VM（内部版本 24.95-b01，混合模式）

如果我还有其他需要，请告诉我。提前致谢！问候，迪维亚·加格

【问题讨论】：

首先，您可以发布有关您的配置的详细信息。您的堆有多大，您正在使用哪些命令行选项等？没有它并且没有任何分析数据，这是一个无法回答的问题。 old gen 中的长时间停顿通常归结为 GC 运行完全压缩的需要。这是 GC 无法跟上分配速率或堆的过度碎片造成的结果。首先尝试增加堆的大小。还有很多其他的建议，但没有更多信息，没有多大意义。
-XX:+UseCompressedOops -XX:+TieredCompilation -Xmx1978m -XX:MaxPermSize=256m -XX:+AggressiveOpts -DOPENSHIFT_APP_UUID=59c0cc814930e9981c000923 -Dorg.jboss.resolver.warning=true -Djava.net。 preferIPv4Stack=true -Dfile.encoding=UTF-8 -Djava.net.preferIPv4Stack=true -Djboss.node.name=9d6nra5nfc4-9d6nra5nfc4.dmp-dev.ficoanalyticcloud.com -Djgroups.bind_addr=127.107.196.129 -Dorg.apache。 coyote.http11.Http11Protocol.COMPRESSION=on -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2
嗨，目前我正在使用 3GB 内存的单个 JVM 上测试我的模拟服务，并尝试将堆空间从 1978MB 增加到 3GB，其中主要 GC 频率从每小时两次变为每 1.6 小时一次，这很好，但我正试图完全摆脱它。是否可以？发现一些未在次要 GC 中收集并提升为旧 GC 的类。请建议我应该具体分析这些课程还是这个正确的方向？

标签： java performance garbage-collection

【解决方案1】：

您提出的问题是“我的车开得不够快，有哪些步骤可以查明发生了什么”。答案是 - 咨询合格的汽车维修服务。

你可以尝试什么：

打开 -XX:+PrintGC 以查看更多正在发生的事情。

大约一小时左右的一次重大 GC 会停止应用程序，这暗示了错误的 GC 配置。通常它发生在内存贪婪的应用程序中，这些应用程序具有大量内存。然后，当时机成熟时，GC 必须清理几千兆字节，这可能会停止处理几分钟。检查parallel collector，或者通常是“垃圾收集调整”，这是一门艺术。

您可能（也可能不会）有内存泄漏问题，请通过配置文件来找出答案（就像您看起来那样）。剖析也是一门艺术。寻找最大的分配以及它们来自哪里，尝试找出为什么它们仍然被引用并且无法清理。

【讨论】：

我现在使用的 JVM Open SDK 1.7.0_95 64 已经在使用并行收集器。根据我的分析，不存在内存泄漏问题。我正在尝试通过降低 VM argsurvivrRatio 来降低它，并且看起来它有助于降低主要的 GC 频率。谢谢