The Enterprise Java Applications on VMware Best Practices Guide is an essential guide for anyone deploying enterprise Java applications on VMware. The guide covers architecture, vCPU, memory, timekeeping, scalability, and other configuration and sizing issues. It contains best practices recommendations and offers help with troubleshooting Java memory and thread contention issues. The Best Practices Guide should be your primary resource for virtualizing Java applications. Using EM4J affects only recommendations concerning JVM memory sizing and memory reservations. This topic describes specific recommendations for using EM4J with ESXi and tc Server.
To prevent ESXi or the OS from swapping, the Best Practices Guide recommends that you size VM memory to accommodate the OS and JVM. The formula presented is:
VMMemory (needed) = GuestOSMemory + JVMMemory
JVMMemory = MaxHeap + PermGen + NumberOfConcurrentThreads * StackSize
The amount consumed by the guest OS memory in this formula includes memory used by the OS and all applications in the VM except the JVM. You can also include in GuestOSMemory the non-heap memory used by the JVM, such as the JIT code cache and byte code interpreter.
JVMMemory includes the following separate memory areas:
Heap memory, which contains the EM4J
balloon, specified with the
PermGen, which contains class level code,
specified with the
-XX:MaxPermSize option (HotSpot
Stack memory, which contains a stack for
each concurrent thread. The size of a single stack is set with the
-Xss option, so you need to multiply the stack size by
the expected number of concurrent threads to calculate the total stack
The Best Practices Guide recommends that you set a reservation for the full amount of VM memory, because if JVM memory is not resident during garbage collection, the swapping can be a serious performance problem. With EM4J, setting a reservation is unnecessary. The recommendation to size VM memory according to the above formula remains valid, but you do not need to reserve the memory. You can also oversize the VM and heap without wasting memory, because excess is ballooned away.