java - G1 垃圾收集器 : Perm Gen fills up indefinitely until a Full GC is performed

Question

我们有一个相当大的应用程序在 JBoss 7 应用服务器上运行。过去，我们使用 ParallelGC，但它在一些堆很大(5 GB 或更多)并且通常几乎填满的服务器中给我们带来了麻烦，我们会经常遇到很长的 GC 暂停。

最近，我们改进了应用程序的内存使用，并在少数情况下为应用程序运行的一些服务器增加了更多 RAM，但我们也开始切换到 G1，希望减少这些暂停的频率和/或更短。事情似乎有所改善，但我们看到了以前没有发生过的奇怪行为(使用 ParallelGC):Perm Gen 似乎很快填满，一旦达到最大值就会触发 Full GC，这通常会导致长时间的暂停在应用程序线程中(在某些情况下，超过 1 分钟)。

几个月来，我们一直在使用 512 MB 的最大 perm 大小，在我们的分析期间，perm 大小通常会在 ParallelGC 的 390 MB 左右停止增长。然而，在我们切换到 G1 之后，上面的行为开始发生。我尝试将最大 perm 大小增加到 1 GB 甚至 1.5 GB，但仍然会发生 Full GC(只是频率较低)。

在 this link您可以看到我们正在使用的分析工具(YourKit Java Profiler)的一些屏幕截图。注意当 Full GC 被触发时，Eden 和 Old Gen 有很多可用空间，但 Perm 大小是最大的。在 Full GC 之后 Perm 大小和加载类的数量急剧减少，但它们又开始上升并重复循环。代码缓存很好，永远不会超过 38 MB(在这种情况下是 35 MB)。

这是GC日志的一部分:

2013-11-28T11:15:57.774-0300: 64445.415: [Full GC 2126M->670M(5120M), 23.6325510 secs] [Eden: 4096.0K(234.0M)->0.0B(256.0M) Survivors: 22.0M->0.0B Heap: 2126.1M(5120.0M)->670.6M(5120.0M)] [Times: user=10.16 sys=0.59, real=23.64 secs]

你可以看到完整的日志 here (从我们启动服务器的那一刻起，直到完全 GC 后的几分钟)。

以下是一些环境信息:

java version "1.7.0_45"

Java(TM) SE Runtime Environment (build 1.7.0_45-b18)

Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

启动选项: -Xms5g -Xmx5g -Xss256k -XX:PermSize=1500M -XX:MaxPermSize=1500M -XX:+UseG1GC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintAdaptiveSizePolicy -Xloggc:gc.log
所以这里是我的问题:

这是 G1 的预期行为吗？我在网上发现另一个帖子，有人质疑非常相似的东西，说 G1 应该在 Perm Gen 上执行增量收集，但没有答案...

我可以改进/纠正我们的启动参数吗？服务器有 8 GB 的 RAM，但似乎我们并不缺乏硬件，在触发完整 GC 之前应用程序的性能很好，那时用户会遇到很大的滞后并开始提示。

Answer 1

Perm Gen 增长的原因

很多类，尤其是 JSP。

很多静态变量。

存在类加载器泄漏。

对于那些不知道的人，这里有一个简单的方法来思考 PremGen 如何填满。年轻一代没有足够的时间让事情到期，所以他们被转移到了老一代的空间。 Perm Gen 持有 Young 和 Old Gen 中对象的类。当 Young 或 Old Gen 中的对象被收集并且该类不再被引用时，它就会从 Perm Gen 中“卸载”。如果 Young 和 Old Gen 中的对象被收集Old Gen 不会被 GC，Perm Gen 也不会，一旦它填满，它就需要一个 Full stop-the-world GC。欲了解更多信息，请参阅 Presenting the Permanent Generation .

切换到 CMS

我知道您正在使用 G1，但如果您确实切换到并发标记扫描 (CMS) 低暂停收集器 -XX:+UseConcMarkSweepGC ，尝试通过添加 -XX:+CMSClassUnloadingEnabled 来启用类卸载和永久生成集合。 .

隐藏的陷阱'

如果您使用 JBoss，RMI/DGC 将 gcInterval 设置为 1 分钟。 RMI 子系统每分钟强制执行一次完全垃圾收集。这反过来又会强制提升而不是让它在年轻一代中被收集。

如果不是 24 小时，您应该将其更改为至少 1 小时，以便 GC 进行适当的收集。

-Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000

每个 JVM 选项的列表

要查看所有选项，请从 cmd 行运行它。

java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version

如果您想查看 JBoss 正在使用什么，那么您需要将以下内容添加到您的 standalone.xml 中。 .您将获得每个 JVM 选项及其设置的列表。注意:它必须在您要查看的 JVM 中才能使用它。如果您在外部运行它，您将看不到运行 JBoss 的 JVM 中发生了什么。

set "JAVA_OPTS= -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal %JAVA_OPTS%"

当我们只对修改后的标志感兴趣时，有一个快捷方式可以使用。

-XX:+PrintcommandLineFlags

诊断

使用 jmap以确定哪些类正在消耗永久代空间。输出将显示

类加载器

类(class)数量

字节

父加载器

生/死

类型

总计

jmap -permstat JBOSS_PID  >& permstat.out

JVM Options

这些设置对我有用，但取决于您的系统如何设置以及您的应用程序正在做什么将决定它们是否适合您。

-XX:SurvivorRatio=8 – 将幸存者空间比例设置为 1:8，从而产生更大的幸存者空间(比例越小，空间越大)。 SurvivorRatio 是伊甸园空间与一个幸存者空间相比的大小。更大的幸存者空间允许短命对象在年轻代中死亡更长的时间。

-XX:TargetSurvivorRatio=90 – 允许 90% 的幸存者空间被占用，而不是默认的 50%，从而更好地利用幸存者空间内存。

-XX:MaxTenuringThreshold=31 – 防止从年轻代过早提升到年老代。允许生命周期较短的对象在年轻代中死亡更长的时间(因此避免升级)。此设置的结果是，由于要复制的额外对象，次要 GC 时间可能会增加。可能需要调整此值和幸存者空间大小，以平衡幸存者空间之间复制的开销与将长期存在的长期对象。 CMS 的默认设置是 SurvivorRatio=1024 和 MaxTenuringThreshold=0，这会导致所有清理的幸存者都被提升。这会给收集年老代的单个并发线程带来很大压力。注意:与 -XX:+UseBiasedLocking 一起使用时，此设置应为 15。

-XX:NewSize=768m – 允许指定初始年轻代大小

-XX:MaxNewSize=768m – 允许指定最大年轻代大小

这是一个更广泛的 JVM options列表。