Just another weblog

  • Subscribe

  • Recent Posts

  • Pages

  • Archives

  • Top Clicks

    • None
  • Advertisements

Are you aware of JVM Ergonomics?

Posted by damuchinni on February 14, 2009

In JDK 5, a new performance feature for self tuning of the JVM known as JVM Ergonomics was added. This is also in JDK 6. The idea is that when the java process gets started, it can examine the underlying system resources and determine some of the tuning parameters (shown below) automatically in the case certain options are not set:

  • If the system is detected as a server class system (i.e. >2 CPU and 2 GB RAM), the server VM is selected (-server)
  • The garbage collector (GC) is changed from the default serial collector (-XX:+UseSerialGC) to a parallel collector (-XX:+UseParallelGC)
  • Heap size setting:
    • initial heap size: Larger of 1/64th of the machine’s physical memory on the machine or some reasonable minimum.
    • maximum heap size: Smaller of 1/4th of the physical memory or 1GB. Before J2SE 5.0, the default maximum heap size was 64MB.
  • Maximum GC pause time goal -XX:MaxGCPauseMillis=<n>
  • Throughput goal -XX:GCTimeRatio=<n> (GC Time : Application time = 1/(1 + n) e.g. -XX:GCTimeRatio=19 (5% of time in GC))
  • Get the rest of the ergonomics feature in this JDK 5 document.

You can override the min and max heap settings -Xms and -Xmx command-line options. In WebSphere Application Server, the min and max heap settings are set with initialHeapSize=”m” and maximumHeapSize=”n” in jvmEntries within the server’s config file server.xml or via the admin console.

The most important thing to note about JVM Ergonomics is that it is performing self-tuning for the specific instance. It has no awareness about other co-existing JVM instances on the system. So, performance issues can arise with some of these self tuning parameters. For example, the parallel collector chosen above also will set the ParallelGCThreads to the number of logical processors on the system. You can determine the number of logical processors (e.g. cores, hardware threads depending on the processor architecture) using the psrinfo command. Assume psrinfo shows 32 “processors”. The JVM instance will inherit “32” GC threads in this case and you should throttle it down to more reasonable setting (e.g. ParallelGCThreads=8). What if you have multiple JVM instances on this system? You’ll have to take all of them into consideration and use appropriate setting of GC threads. If not, imagine you will run into situation where you will end up with too many threads on the system (32*# of instances for GC threads alone) — causing unwanted resource contention.

You will have to go through some iterative testings to see what would be optimal for your applications. You should also consider using other available GC policies such as -XX:+UseSerialGC or -XX:+UseConcMarkSweepGC. You can find out more about it in this GC Tuning in JDK 5 whitepaper.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: