Skip to main content

Auto-detection of number of parallel GC threads

3 replies [Last post]
samuelto
Offline
Joined: 2005-03-15
Points: 0

For failover/stability and also to avoid synchronization/gc impacts, we start multiple JVMs to run our business application on an application server.

Recently when we were doing a benchmark with JDK1.5.0_05, we noticed unusually long minor GC times and high CPU usage on the box. Turns out the box has 20 CPUs and when we start 5 JVMs on the box there is too much activity from those threads (we were just using -Xmx1024m)

By adding -XX:ParallelGCThreads=4, everything came back to normal.

I have several questions related to this:
1. Are there any JVM options to make it detect other JVMs running and adjust ParallelGCThreads automatically?

2. If not, are there plans to add such an option?

3. What would be a reasonable formula for deciding ParallelGCThreads? Something like (#CPU / #JVM)?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
tmarble
Offline
Joined: 2003-08-22
Points: 0

Please try your benchmark with 1.5.0_06 as well...

Many performance enhancements were added in
that update release.

Regards,

--Tom

jon999
Offline
Joined: 2006-02-15
Points: 0

1. There are no JVM options to make the garbage collector select the number of GC threads based on the load on the platform.

2. There have been proposes to set parameters such as the heap size and number of GC threads (among other parameters) dynamically during the JVM execution. It is not a committed item for a particular release yet.

3. In deciding how many GC threads to use, leave one available for the OS. So 1 JVM should get (#cpu / #jvm) - 1. The rest can get (#cpu / #jvm). This choice is based on avoiding the very long pauses that you mentioned. You may have to adjust it if the system is otherwise loaded. It may not always be the best for total performance of the JVM's. I don't have a rule for the latter.

alexlamsl
Offline
Joined: 2004-09-02
Points: 0

I think the upcoming MVM would resolve this problem in a straight-forward way.