Over-Committing Memory with EM4J

When you run Java applications on ESXi without EM4J, it is important to completely reserve VM memory to avoid thrashing during garbage collection. When EM4J is enabled and ESXi needs to reclaim memory, the JVM is placed under pressure to manage memory conservatively. Memory in the Java heap not used for application objects can be reclaimed by ESXi for use by other VMs. This means that you do not have to reserve VM memory with EM4J. You can create more VMs, over-committing the physical memory, and improving your consolidation ratio.

The amount you can safely over-commit, of course, varies depending on application behavior, loads, and other factors. Experiment by gradually increasing the over-commit and measuring your applications' response times. Response times will only increase when memory pressure becomes significant, increasing garbage collection. With lower levels of over-commit, response times may not be affected at all. EM4J has been tested with memory over-committed up to 40% with good results.

One way to evaluate the memory pressure on the VM is to monitor the difference (delta) between the balloon target and balloon size. If the balloon size is smaller than the target for a significant time, the memory pressure on the VM is too high.

Ultimately, your physical memory must accommodate the maximum active data set for all VMs to avoid performance degradation. Ballooning can only reclaim unused memory. If your applications have large amounts of long-lived live data, your over-commit ratio will be smaller. As an optimization, the JVM moves objects in heap that survive multiple GCs to the tenured generation. As the size of the tenured area of the heap grows, the potential EM4J balloon size shrinks. You can observe this happening by monitoring the difference between the Balloon Target and Balloon size in the vSphere Client, or by monitoring the EM4J MBeans via JMX. In particular, the com.springsource.balloon.jmx.JvmBalloonState MBean shows the size of the tenured generation in the JVM. If the tenured area of the JVM grows to consume a large portion of the heap, you will have to reduce your over-commit.