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 a primary resource for virtualizing Java applications.
Using EM4J affects recommendations concerning JVM memory sizing and memory reservations. This topic describes specific recommendations for using EM4J with ESXi and tc Server.
The vSphere Web client EM4J plug-in adds the Workloads tab to the vSphere Web Client to display information collected by the EM4J Console Guest Collector. The memory usage statistics and graphs available on the Workloads tab can help you to set optimal sizes for virtual memory and JVM heaps.
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 is an estimate of memory used by the OS and all applications in the VM except the JVM. You can also include in the GuestOSMemory estimate 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 application
data and 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.
It is difficult to discover the optimum amount of heap memory a Java application requires without visibility into the Java heap. The vSphere Web Client, with the EM4J plug-in, illustrates how memory is used in a virtual machine, in both real time and over a period of time. It can help you discover over- and undersized VMs and Java heaps and alert you to performance problems before they happen. See Monitoring Memory with the vSphere Web Client to learn about this feature.