3

我们正在使用以下启动参数运行 JBoss，但在 GC 时间长（> 5 分钟）方面存在问题。

-Xms116042m -Xmx116042m -XX:PermSize=256M -XX:MaxPermSize=256M -XX:+UseConcMarkSweepGC -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:MaxHeapFreeRatio=95

关于我们如何最小化 GC 时间的任何建议？

注意：这些是 16 个四核 cpu，128GB linux 机器。

GC 日志：

"CMSbailing out to foreground collection"我在 GC 日志中看到许多消息：

130904.206: [GC 130904.206: [ParNew: 240819K->25522K(249216K), 0.2391170 secs] 80798776K->80588205K(118799360K), 0.2395380 secs] [Times: user=2.56 sys=0.01, real=0.24 secs] 
130904.799: [GC 130904.799: [ParNew: 247018K->27648K(249216K), 0.2071170 secs] 80809700K->80601600K(118799360K), 0.2075260 secs] [Times: user=2.61 sys=0.00, real=0.21 secs] 
130905.455: [GC 130905.455: [ParNew: 249216K->27648K(249216K), 0.2808950 secs] 80823168K->80644147K(118799360K), 0.2813140 secs] [Times: user=2.66 sys=0.00, real=0.28 secs] 
130905.765: [Full GC (System) 130905.765: [**CMSbailing out to foreground collection**
131167.602: [CMS-concurrent-mark: 284.753/303.276 secs] [Times: user=909.49 sys=193.05, real=303.23 secs] 
 (concurrent mode interrupted): 80616499K->74658646K(118550144K), 554.7507700 secs] 80651365K->74658646K(118799360K), [CMS Perm : 112620K->112582K(262144K)], 554.7511550 secs] [Times: user=784.15 sys=175.10, real=554.65 secs] 
131461.127: [GC 131461.128: [ParNew: 221568K->27648K(249216K), 0.2620780 secs] 74880214K->74691531K(118799360K), 0.2624960 secs] [Times: user=2.28 sys=0.00, real=0.27 secs] 
131461.698: [GC 131461.699: [ParNew: 249216K->27647K(249216K), 0.3827130 secs] 74913099K->74807895K(118799360K), 0.3829550 secs] [Times: user=3.52 sys=0.41, real=0.39 secs] 
131462.754: [GC 131462.754: [ParNew: 249215K->27648K(249216K), 0.3022410 secs] 75029463K->74827673K(118799360K), 0.3026050 secs] [Times: user=2.36 sys=0.02, real=0.30 secs] 
131463.789: [GC 131463.790: [ParNew: 249216K->22291K(249216K), 0.2396390 secs] 75049241K->74841234K(118799360K), 0.2400980 secs] [Times: user=2.38 sys=0.06, real=0.24 secs]
4

5 回答 5

1

无论您使用 conc 标记还是并行 gc，清除 116 Gb 的垃圾总是会花费很多时间。我总是发现这个文档是调整 GC 最有用的信息来源。GC 调整将根据您的应用程序需求而定，没有通用的解决方案，但有很多可用的选项。

你可能对 G1GC 有更多的运气，因为它将堆分成许多小部分并独立地清扫它们，但它仍然可能容易受到随机 OOME 的影响。

如果调整 GC 无法产生足够的响应时间，请将机器拆分为多个 16 到 32 Gb RAM 的虚拟机并将其集群化。如果它是一个 EJB 应用程序，并且你正确地烤了你的 bean，它可能不像看起来那么痛苦。

于 2012-12-12T04:39:45.510 回答
0

您可以将初始堆设置为较小的值。通过这样做，启动时间将减少。由于java不想在启动时分配一个非常大的堆。这将为 GC 节省一些时间，因为它通常会运行相对较小的堆。

于 2012-12-12T09:33:58.287 回答
0

我观察到发生完全 GC 的一个原因是因为你的年轻代比要求的更快被填满，这需要将对象复制到老一代。所以我们可以尝试以下选项

  1. 为年轻代设置初始大小，如下所示 -XX:NewSize=500m -XX:MaxNewSize=500m

  2. 您可以为年轻代设置一个配给作为老年代的一个因素 –XX:NewRatio=3

希望这可以帮助...

于 2012-12-12T04:00:31.247 回答
0

将 Java 堆大小设置得如此接近物理可用内存并不是一个好主意，除了使用 -Xmx 配置的内容之外，总是会使用相当多的开销。如果您有很多线程，则堆栈将需要相当多的时间。您是否查看过例如“vmstat 1”的输出以查看它是否正在交换？

于 2013-11-11T13:36:24.490 回答
0

由于您看到消息“并发模式中断”，并且在 GC 时似乎您的世代都没有满，我认为有一个明确的 System.gc() 调用导致您的完整 GC。尝试添加 JVM 参数 -XX:+ExplicitGCInvokesConcurrent 以使 System.gc() 调用调用 CMS。此外，如果您自己调用 System.gc()，请确定原因并尽可能删除。

于 2012-12-12T15:13:01.957 回答