Virtualized Java is the Real Deal

Lately, I've been talking to more and more virtualization gurus and while most of my conversations are still with Java architect or middleware operations teams, change is coming. VMWare's acquisition of SpringSource has flung the virtualize Java door wide open. And, the biggest challenge we face is not technical. We need cross pollination of Java and virtualization talent. Virtualization gurus need to ramp on Java, and Java gurus need to ramp up on virtualization. I realize that virtualization gurus should not concern themselves with programming in Java. But, they do need to understand the tools of the trade, the strengths/weaknesses of the platform and configuration optimization techniques. My next series of blogs will target the virtualization guru audience. Here is a little taste of what is coming:

Quick JVM Optimization Checklist

• 64-bit JVM - If you see 32-bit Windows/Linux, recommend a move to a 64-bit operating system(OS) and Java Virtual Machine(JVM). The 4GB limit on a 32-bit OS is problematic for large enterprise Java applications. And, since the 4GB limit is for the entire OS, the maximum JVM allocation will range from 2GB to 3.5GB, depending on the OS. In a future blog, I will go into more detail on why Java can consume a ridiculously large amount of memory and why that is not necessarily a bad thing.
• Min/Max Heap - Min=minimum heap size of the JVM, Max=maximum heap size of the JVM. The JVM manages memory similar to a hypervisor and the JVM's memory consumption will balloon up/down based on application design and user load. If the max heap setting is too low, the JVM will spend an inordinate amount of time managing memory. Or, worse yet throw an OOME(Out of Memory Exception). If the max memory setting is too high, memory is wasted because the ESX hypervisor will not be able to reclaim it from the JVM. Right now, memory management for Java is Highlander style, "There can only be one". You cannot drop memory reservations down on VMs that are running Java. But, if you set reservations properly, Java application performance on VMs will be similar to physical. For a development system, max heap will often be 512MB or lower on a lightweight application server like Tomcat. On a production system, anything lower than 1024MB is cause for concern, but not necessarily wrong. Many Java gurus will insist on setting min/max to the same value, but that is no longer required for most deployments. Prior to JVM 1.5 or Java 5, setting min/max to the same value was a no-brainer.
• Permgen - The default permgen, if not specified, is 64MB and that is usually far too low. Permgen is the region of JVM memory that cannot be reclaimed. It is similar to the reservation in the hypervisor, but different. When you deploy an application to the JVM, the bytecode for all classes are loaded into the permgen region. If the application is large or uses a lot of framework JARs, it will require more permgen. Other memory may reside in permgen but this classloading activity is what causes most OOMEs that are permgen related. When the OOME is permgen related, you will see this message in the server log: "OutOfMemoryError: PermGen space". Application hot-deploys are usually the culprit. Most application servers support live deployment of a new application. There are JVM tricks to make hot-deploy work without killing permgen, but hot deploys should NEVER HAPPEN IN PRODUCTION. I will go so far as to say they should never happen outside of a developer workstation.

This is a small sliver of JVM optimization information but understanding how to properly configure min/max/perm will address a surprisingly large number of Java performance issues. More information about JVM tuning can be found here: http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html.

I will continue my virtualization ramp process by reading great blogs like: http://www.virtualinsanity.com and I believe that every Java guru needs to learn more about virtualization. Hopefully virtualization gurus will find this blog useful.

DISCLAIMER: I am employed by VMWare. The views expressed on this blog do not necessarily reflect the views of my employer. I am completely responsible for all content displayed here. Furthermore, no content of cfossguy.blogspot.com has ever been reviewed and/or endorsed by my employer.