30

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

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

几个月来,我们一直在使用 512 MB 的最大 perm 大小,在我们的分析过程中,使用 ParallelGC 时,perm 大小通常会停止增长到 390 MB 左右。然而,在我们切换到 G1 之后,上述行为开始发生。我尝试将最大 perm 大小增加到 1 GB 甚至 1.5 GB,但仍然会发生 Full GC(它们只是不太频繁)。

此链接中,您可以看到我们正在使用的分析工具(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:[完整 GC 2126M->670M(5120M),23.6325510 秒] [伊甸园:4096.0K(234.0M)->0.0B(256.0M) 幸存者:22.0M- >0.0B 堆:2126.1M(5120.0M)->670.6M(5120.0M)] [时间:用户=10.16 系统=0.59,实际=23.64 秒]

您可以在此处查看完整的日志(从我们启动服务器的那一刻起,直到完整 GC 后的几分钟)。

以下是一些环境信息:

java版本“1.7.0_45”

Java(TM) SE 运行时环境 (build 1.7.0_45-b18)

Java HotSpot(TM) 64 位服务器 VM(内部版本 24.45-b08,混合模式)

启动选项:-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,这就是用户体验大滞后并开始抱怨的时候。

4

5 回答 5

33

烫发生长的原因

  • 很多类,尤其是 JSP。
  • 大量静态变量。
  • 有一个类加载器泄漏。

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


切换到 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确定哪些类正在消耗永久代空间。输出将显示

  • 类加载器
  • # 类
  • 字节
  • 父加载器
  • 活着/死去
  • 类型
  • 总计

    jmap -permstat JBOSS_PID  >& permstat.out
    

JVM 选项

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

  • -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 选项列表。

于 2013-12-03T21:41:47.667 回答
2

这是 G1 的预期行为吗?

我不觉得奇怪。基本假设是放入 permgen 的东西几乎永远不会变成垃圾。所以你会期望 permgen GC 将是“最后的手段”;即 JVM 只有在强制进入完整 GC 时才会这样做。(好吧,这个论点远非证明......但它与以下内容一致。)

我已经看到很多证据表明其他收藏家也有同样的行为。例如

我在网上找到另一个帖子,有人质疑非常相似的事情,并说 G1 应该在 Perm Gen 上执行增量收集,但没有答案......

我想我找到了同样的帖子。但是有人认为它应该是可能的并没有真正的指导意义。

我们的启动参数有什么可以改进/纠正的吗?

我对此表示怀疑。我的理解是,这是 permgen GC 策略所固有的。

我建议您要么首先追踪并修复正在使用这么多 permgen 的东西……要么切换到不再有 permgen 堆的 Java 8:请参阅JDK 8 中的 PermGen 消除

虽然 permgen 泄漏是一种可能的解释,但还有其他解释;例如

  • 过度使用String.intern(),
  • 执行大量动态类生成的应用程序代码;例如使用DynamicProxy,
  • 一个巨大的代码库......尽管这不会像您所观察到的那样导致永久流失。
于 2013-12-06T09:38:12.030 回答
1

在随机尝试 JVM 选项之前,我会首先尝试找到 PermGen 变大的根本原因。

  • 您可以启用类加载日志记录 (-verbose:class, -XX:+TraceClassLoading -XX:+TraceClassUnloading, ...) 并检查输出
  • 在您的测试环境中,您可以尝试监控(通过 JMX)何时加载类 (java.lang:type=ClassLoading LoadedClassCount)。这可能会帮助您找出应用程序的哪个部分负责。
  • 您还可以尝试使用 JVM 工具列出所有类(抱歉,我仍然主要使用 jrockit,您可以使用 jrcmd 来完成。希望 Oracle 已将这些有用的功能迁移到 Hotspot ......)

总之,找出产生这么多类的原因,然后考虑如何减少/调整 gc。

干杯,迪莫

于 2013-12-04T12:14:23.540 回答
1

我同意上面的答案,因为您应该真正尝试找到实际填充您的 permgen 的内容,并且我严重怀疑这是您想要找到根本原因的一些类加载器泄漏。

JBoss 论坛中有这个帖子,其中介绍了几个这样的诊断案例以及它们是如何修复的。这个答案这篇文章也讨论了这个问题。在那篇文章中提到了您可以做的最简单的测试:

症状

仅当您重新部署应用程序而不重新启动应用程序服务器时才会发生这种情况。JBoss 4.0.x 系列就遭受了这样的类加载器泄漏。结果,在 JVM 耗尽 PermGen 内存并崩溃之前,我无法重新部署我们的应用程序两次以上。

解决方案

要识别此类泄漏,请取消部署您的应用程序,然后触发完整的堆转储(确保在此之前触发 GC)。然后检查是否可以在转储中找到任何应​​用程序对象。如果是这样,请按照他们对根目录的引用,您将找到类加载器泄漏的原因。对于 JBoss 4.0,唯一的解决方案是每次重新部署都重新启动。

如果您认为重新部署可能相关,这是我首先要尝试的。这篇博文是较早的一篇,做同样的事情,但也讨论了细节。根据帖子,虽然您实际上并没有重新部署任何东西,但 permgen 只是自行填充。在这种情况下,检查类+添加到 permgen 的任何其他内容可能是一种方式(正如前面的答案中已经提到的那样)。

如果这不能提供更多洞察力,我的下一步将是尝试plumbr tool。他们也可以保证为您找到泄漏

于 2013-12-06T09:33:38.040 回答
-3

您应该使用带有 -verbose:gc 的 java 命令启动 server.bat

于 2013-12-03T20:15:23.403 回答