UseConcMarkSweepGC 与 UseParallelGC答案

【问题标题】：UseConcMarkSweepGC vs UseParallelGCUseConcMarkSweepGC 与 UseParallelGC
【发布时间】：2012-02-18 19:25:31
【问题描述】：

我目前遇到垃圾收集时间过长的问题。请参阅以下内容。我当前的设置是我正在使用 -Xms1g 和 -Xmx3g。我的应用程序使用的是 java 1.4.2。我没有设置任何垃圾收集标志。从外观上看，3gb 是不够的，我真的有很多对象要垃圾收集。

问题：

我应该改变我的垃圾收集算法吗？我应该用什么？用-XX:+UseParallelGC or -XX:+UseConcMarkSweepGC会更好

或者我应该使用这个组合

-XX:+UseParNewGC -XX:+UseConcMarkSweepGC

占用内存的主要是报表数据，而不是缓存数据。另外，机器有 16gb 内存，我计划将堆增加到 8gb。

这两个选项之间有什么区别，因为我仍然很难理解。机器有多个处理器。我最多可以承受 5 秒的打击，但 30 到 70 秒真的很难。

感谢您的帮助。

  Line 151493: [14/Jan/2012:11:47:48] WARNING ( 8710): CORE3283: stderr: [GC 1632936K->1020739K(2050552K), 1.2462436 secs]
    Line 157710: [14/Jan/2012:11:53:38] WARNING ( 8710): CORE3283: stderr: [GC 1670531K->1058755K(2050552K), 1.1555375 secs]
    Line 163840: [14/Jan/2012:12:00:42] WARNING ( 8710): CORE3283: stderr: [GC 1708547K->1097282K(2050552K), 1.1503118 secs]
    Line 169811: [14/Jan/2012:12:08:02] WARNING ( 8710): CORE3283: stderr: [GC 1747074K->1133764K(2050552K), 1.1017273 secs]
    Line 175879: [14/Jan/2012:12:14:18] WARNING ( 8710): CORE3283: stderr: [GC 1783556K->1173103K(2050552K), 1.2060946 secs]
    Line 176606: [14/Jan/2012:12:15:42] WARNING ( 8710): CORE3283: stderr: [Full GC 1265571K->1124875K(2050552K), 25.0670316 secs]
    Line 184755: [14/Jan/2012:12:25:53] WARNING ( 8710): CORE3283: stderr: [GC 2007435K->1176457K(2784880K), 1.2483770 secs]
    Line 193087: [14/Jan/2012:12:37:09] WARNING ( 8710): CORE3283: stderr: [GC 2059017K->1224285K(2784880K), 1.4739291 secs]
    Line 201377: [14/Jan/2012:12:51:08] WARNING ( 8710): CORE3283: stderr: [Full GC 2106845K->1215242K(2784880K), 30.4016208 secs]


xaa:1: [11/Oct/2011:16:00:28] WARNING (17125): CORE3283: stderr: [Full GC 3114936K->2985477K(3114944K), 53.0468651 secs] --> garbage collection occurring too often as noticed in the time. garbage being collected is quite low and if you would notice is quite close the the heap size. during the 53 seconds, this is equivalent to a pause.
xaa:2087: [11/Oct/2011:16:01:35] WARNING (17125): CORE3283: stderr: [Full GC 3114943K->2991338K(3114944K), 58.3776291 secs]
xaa:3897: [11/Oct/2011:16:02:33] WARNING (17125): CORE3283: stderr: [Full GC 3114940K->2997077K(3114944K), 55.3197974 secs]
xaa:5597: [11/Oct/2011:16:03:00] WARNING (17125): CORE3283: stderr: [Full GC[Unloading class sun.reflect.GeneratedConstructorAccessor119]
xaa:7936: [11/Oct/2011:16:04:36] WARNING (17125): CORE3283: stderr: [Full GC 3114938K->3004947K(3114944K), 55.5269911 secs]
xaa:9070: [11/Oct/2011:16:05:53] WARNING (17125): CORE3283: stderr: [Full GC 3114937K->3012793K(3114944K), 70.6993328 secs]

【问题讨论】：

这里是可能对您有帮助的链接oracle.com/technetwork/java/gc-tuning-5-138395.html。收集器是 1.5 特有的，并行和并发扫描的概念在 1.4 中可能相同。

标签： java performance garbage-collection g1gc concurrent-mark-sweep

【解决方案1】：

由于您的 GC 暂停时间非常长，因此您认为更改 GC 算法不会有帮助。

请注意，您只有完整的收藏是非常可疑的。也许您需要增加年轻代和/或幸存者空间的大小。

另请参阅：

Tuning Garbage Collection with the 1.4.2 Java[tm] Virtual Machine

【讨论】：

是的，它仅在生成报告时发生。这些是来自数据库的对象，它们的值非常大。我想知道是否有无论如何我可以解决这个问题。在场景 2 中，我认为堆大小确实不足，这就是我们计划增加它的原因，对于场景 1，堆仍然可用。 gc 大约是 25 到 30 秒。
很抱歉，我无法在其中包含其他 gc。现在将它包含在第一个场景中。

【解决方案2】：

你的堆太小了。暂停是如此之大，因为它正忙于反复扫描整个堆，拼命寻找要收集的东西。

您需要执行以下一项或多项操作；

查找并修复内存泄漏
调整应用程序以使用更少的内存
配置 JVM 使用更大的堆

由于某种原因，您是否与 1.4.2 相关联？从那时起，GC 实现确实已经发展，所以如果可能的话，你应该考虑升级。我意识到这可能是一项艰巨的任务，但无论如何都值得考虑。

【讨论】：

实际上，它只发生在用户开始生成大型报告并且我们确实无法控制的情况下。报告真的很大。目前，1.4.2 是我们所在的服务器，迁移的过程就在那里，但我们现在需要尽我们所能。
对于场景 1，我仍然有可用的堆，因为我的最大堆为 3gb，但垃圾收集仍然太长。
如果生成大型报告是正常操作的一部分，那么您的堆就太小了。但是，您需要进行一些适当的基准测试来调整它，如果您迁移到 java6 或 java7 jvm，那么这项工作的输出将至少部分是多余的。如果你能帮上忙，你不想做同样的工作两次。
对于场景 1，您需要收集更多关于堆形状的数据。您需要查看的标志是 PrintTenuringDistribution、verbose:gc、-Xloggc:gc.log、PrintGCDetails 和 PrintGCTimeStamps。一旦你有了这些信息，人们就可以就可能立即受益的合理调整步骤提供建议。毕竟，对于一个年轻的集合来说，超过 1 秒是巨大的。
fwiw 1.4 中的默认收集器 iirc 是单线程串行收集器。只需添加-XX:+UseParallelGC 几乎肯定会大大减少年轻系列中的 STW 时间。请注意，您必须切换到 CMS 以改进终身收集器，因为据我记得 1.4 中没有 paralleloldgc。因此，一个好的策略可能是更大的堆和吞吐量收集器。然而，更大的堆意味着当一个终身收集发生时，它可能真的很长。还要记住，CMS 需要比并行收集器更大的堆才能工作。

【解决方案3】：

如果你的存活率很高，你的堆可能太大了。堆越大，JVM 可以在没有 GC 的情况下运行的时间越长，因此一旦命中，它就有更多的移动空间。

【讨论】：

【解决方案4】：

第 1 步：

确保您已为应用程序设置了足够的内存。
确保您的应用程序中没有内存泄漏。 Eclipse Memory Analyzer Tool 或 visualvm 将帮助您识别应用程序中的泄漏。

第 2 步：

如果您对第 1 步没有任何关于内存泄漏的问题，请参阅 oracle 文档 page“Java 垃圾收集器”部分中特定垃圾收集算法的用例和 gctuning 文章。

由于您已决定配置更大的堆 (>= 8 GB)，G1GC 应该适合您。有关微调关键参数，请参阅此相关 SE 问题：

Java 7 (JDK 7) garbage collection and documentation on G1

【讨论】：