Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

UseConcMarkSweepGC vs UseParallelGC

I'm currently having problems with very long garbage collection times. please see the followig. My current setup is that I'm using a -Xms1g and -Xmx3g. my application is using java 1.4.2. I don't have any garbage collection flags set. by the looks of it, 3gb is not enough and I really have a lot of objects to garbage collect.

question:

should I change my garbage collection algorithm? what should i use? is it better to use -XX:+UseParallelGC or -XX:+UseConcMarkSweepGC

or should i use this combination

-XX:+UseParNewGC -XX:+UseConcMarkSweepGC 

the ones occupying the memory are largely reports data and not cache data. also, the machine has 16gb memory and I plan to increase the heap to 8gb.

What are the difference between the two options as I still find it hard to understand. the machine has multiple processors. I can take hits of up to 5 seconds but 30 to 70 seconds is really hard.

Thanks for the help.

  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] 
like image 414
grassbl8d Avatar asked Jan 25 '12 15:01

grassbl8d


People also ask

Which garbage collector is best?

ZGC is a low-latency garbage collector that works well with very large (multi-terabyte) heaps. Like G1, ZGC works concurrently with the application. ZGC is concurrent, single-generation, region-based, NUMA-aware, and compacting. It does not stop the execution of application threads for more than 10ms.

What is UseParallelGC?

The parallel scavenge collector (Enabled using -XX:UseParallelGC). This is like the previous parallel copying collector, but the algorithm is tuned for gigabyte heaps (over 10GB) on multi-CPU machines. This collection algorithm is designed to maximize throughput while minimizing pauses.

What is the fastest garbage collector in Java 8?

The results are clear: That default (Parallel GC) is the fastest.

Is G1GC better than CMS?

Comparing G1 with CMS reveals differences that make G1 a better solution. One difference is that G1 is a compacting collector. Also, G1 offers more predictable garbage collection pauses than the CMS collector, and allows users to specify desired pause targets.


2 Answers

Since you have extremenly long GC pauses, it's don't think that changing GC algorithm would help.

Note that it's highly suspicious that you have only full collections. Perhaps you need to increase the size of young generation and/or survivor space.

See also:

  • Tuning Garbage Collection with the 1.4.2 Java[tm] Virtual Machine
like image 152
axtavt Avatar answered Sep 18 '22 11:09

axtavt


Your heap is too small. The pause is so large because it's busy repeatedly scanning the entire heap desperately looking for anything to collect.

You need to do 1 or possibly more of the following;

  • find and fix a memory leak
  • tune the application to use less memory
  • configure the JVM is use a bigger heap

Are you tied to 1.4.2 for some reason? GC implementations really have moved on since then so you should consider upgrading if possible. I realise this may be a non trivial undertaking but it's worth considering anyway.

like image 33
Matt Avatar answered Sep 22 '22 11:09

Matt