UseConcMarkSweepGC vs UseParallelGC

时间:2012-01-25 15:49:55

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

我目前遇到很长时间的垃圾回收问题。请参阅以下内容。我目前的设置是我使用-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]

4 个答案:

答案 0 :(得分:7)

由于您有极长的GC暂停,因此不认为更改GC算法会有所帮助。

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

另见:

答案 1 :(得分:4)

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

您需要执行以下1个或更多个操作;

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

由于某种原因你是否与1.4.2挂钩? GC实现从那时起就开始了,所以你应该考虑升级,如果可能的话。我意识到这可能是一件非常重要的事情,但无论如何都值得考虑。

答案 2 :(得分:1)

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

答案 3 :(得分:1)

第1步:

  1. 确保为应用程序设置了足够的内存。
  2. 确保应用程序中没有内存泄漏。 Eclipse Memory Analyzer Toolvisualvm将帮助您识别应用程序中的泄漏。
  3. 第2步:

    如果您对步骤1中的内存泄漏没有任何问题,请参阅oracle文档page,了解“Java垃圾收集器”部分和gctuning中特定垃圾收集算法的用例制品

    由于您已决定配置更大的堆(> = 8 GB),因此G1GC应该可以正常工作。请参阅有关微调关键参数的相关SE问题:

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