Are you aware of JVM Ergonomics?
By sunabl on Feb 12, 2009
- 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.