Comments on: Drastically reducing GC pause times for YQL http://www.javarants.com/2009/11/03/drastically-reducing-gc-pause-times-for-yql/ Rants about Java and other internet technologies by Sam Pullara Mon, 08 Mar 2010 00:20:15 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: spullara http://www.javarants.com/2009/11/03/drastically-reducing-gc-pause-times-for-yql/comment-page-1/#comment-1020 spullara Sun, 08 Nov 2009 00:05:43 +0000 http://www.javarants.com/?p=1241#comment-1020 Could it be the type of workloads you are throwing at it? We've had 30 VMs under load in production for the last week with great, low pause times without a hint of instability. I'll take a crack at it with your options and see what we see. G1 so far has been useless with full pauses being long and frequent under moderate testing. Ran a 24 hour test last night of JRockit and their deterministic GC with excellent results for our workloads. We also don't use Solaris. It is all RHEL. Could it be the type of workloads you are throwing at it? We've had 30 VMs under load in production for the last week with great, low pause times without a hint of instability. I'll take a crack at it with your options and see what we see. G1 so far has been useless with full pauses being long and frequent under moderate testing. Ran a 24 hour test last night of JRockit and their deterministic GC with excellent results for our workloads. We also don't use Solaris. It is all RHEL.

]]> By: spullara http://www.javarants.com/2009/11/03/drastically-reducing-gc-pause-times-for-yql/comment-page-1/#comment-998 spullara Sat, 07 Nov 2009 16:05:43 +0000 http://www.javarants.com/?p=1241#comment-998 Could it be the type of workloads you are throwing at it? We've had 30 VMs under load in production for the last week with great, low pause times without a hint of instability. I'll take a crack at it with your options and see what we see. G1 so far has been useless with full pauses being long and frequent under moderate testing. Ran a 24 hour test last night of JRockit and their deterministic GC with excellent results for our workloads. We also don't use Solaris. It is all RHEL. Could it be the type of workloads you are throwing at it? We've had 30 VMs under load in production for the last week with great, low pause times without a hint of instability. I'll take a crack at it with your options and see what we see. G1 so far has been useless with full pauses being long and frequent under moderate testing. Ran a 24 hour test last night of JRockit and their deterministic GC with excellent results for our workloads. We also don't use Solaris. It is all RHEL.

]]> By: Ari Zilka http://www.javarants.com/2009/11/03/drastically-reducing-gc-pause-times-for-yql/comment-page-1/#comment-997 Ari Zilka Sat, 07 Nov 2009 02:54:30 +0000 http://www.javarants.com/?p=1241#comment-997 Uhm, our work with the JVM shows Concurrent collector highly unstable and several folks in high places who shall remain nameless say never to use it. Also, OS / platform is important. On Solaris / CMT, run LargePageSizes and about as many ParallelGC threads as you have CMT threads (32, 64, or 128). <br><br>-XX:SurvivorRatio=8 – large survivor spaces for short-lived objects<br>-XX:+UseParallelGC<br>-XX:ParallelGCThreads=20<br>-XX:+UseParallelOldGC<br>-Xmn1g<br>-server switch<br><br>Last, if you insist on CMS, then we have used ParNewGC + CMS and initiatingOccupancyFraction to get the GC to kick off aggressively and keep down the Full pauses. <br><br>G1 is going to have to dig us all out of the whole the CMS is burying us in, but Parallel w/ LOTS of threads has proved way more stable for us w/o the stop-the-worlds from CMS that can be like 3 hours... Uhm, our work with the JVM shows Concurrent collector highly unstable and several folks in high places who shall remain nameless say never to use it. Also, OS / platform is important. On Solaris / CMT, run LargePageSizes and about as many ParallelGC threads as you have CMT threads (32, 64, or 128).

-XX:SurvivorRatio=8 – large survivor spaces for short-lived objects
-XX:+UseParallelGC
-XX:ParallelGCThreads=20
-XX:+UseParallelOldGC
-Xmn1g
-server switch

Last, if you insist on CMS, then we have used ParNewGC + CMS and initiatingOccupancyFraction to get the GC to kick off aggressively and keep down the Full pauses.

G1 is going to have to dig us all out of the whole the CMS is burying us in, but Parallel w/ LOTS of threads has proved way more stable for us w/o the stop-the-worlds from CMS that can be like 3 hours…

]]> By: spullara http://www.javarants.com/2009/11/03/drastically-reducing-gc-pause-times-for-yql/comment-page-1/#comment-995 spullara Wed, 04 Nov 2009 13:08:38 +0000 http://www.javarants.com/?p=1241#comment-995 We are currently on java version 1.6.0_16. We haven't yet seen a crash with this configuration. We are currently on java version 1.6.0_16. We haven't yet seen a crash with this configuration.

]]> By: Amit Naik http://www.javarants.com/2009/11/03/drastically-reducing-gc-pause-times-for-yql/comment-page-1/#comment-993 Amit Naik Wed, 04 Nov 2009 07:02:33 +0000 http://www.javarants.com/?p=1241#comment-993 Which specific version of 1.6 are you using? We have seen some GC related crashes with 1.6_06, 14,15 while using the CMS collector so we switched back to using the throughput collector. Did you happen to run into this? Which specific version of 1.6 are you using? We have seen some GC related crashes with 1.6_06, 14,15 while using the CMS collector so we switched back to using the throughput collector. Did you happen to run into this?

]]> By: h0h0h0 http://www.javarants.com/2009/11/03/drastically-reducing-gc-pause-times-for-yql/comment-page-1/#comment-992 h0h0h0 Wed, 04 Nov 2009 03:04:47 +0000 http://www.javarants.com/?p=1241#comment-992 Tight. I love the black magic that you can get with some of the JVM parameters. It's a whole new world over them thar hills. Tight. I love the black magic that you can get with some of the JVM parameters. It's a whole new world over them thar hills.

]]>