This chapter explains principles for right-sizing VMs with Java workloads and explains how to interpret the historical data on the vSphere Web Client Workloads tab.
The Enterprise Java Applications on VMware Best Practices Guide is a primary resource for virtualizing Java applications and is essential for anyone deploying enterprise Java applications on VMware. The guide covers architecture, vCPU, memory, timekeeping, scalability, and other configuration and sizing considerations. It contains best practices recommendations and offers help with troubleshooting Java memory and thread contention issues.
To add the EM4J Plug-in to your vSphere Web Client, see Install the vSphere Web Client EM4J Plug-in.
This chapter focuses on using the historical data on the Workloads tab to understand VM and Java heap memory use.
For more details about Workloads tab information, see Viewing Java Workloads in the vSphere Web Client.
You create a virtual machine with a specified amount of memory. ESXi virtualizes the memory, backing virtual memory with physical memory completely transparently to the guest OS. ESXi can supply more virtual memory to guests than the host has physical memory, and that makes it possible to over-commit host memory by a certain amount without affecting performance.
It can be challenging to determine how much vRAM to allocate to VMs; how many VMs a host should support; and by how much the host memory can be over-committed. A VM needs sufficient memory to support its applications without resorting to expensive OS page swapping, but not much more than is required at its heaviest load. Oversizing a VM allows the guest OS to consume the excess memory for low-priority uses, such as file buffering and caching, and reduces the host's over-commit potential.
When guests run Java workloads, there is an additional challenge to size the Java heap memory to consume the guest's vRAM efficiently and still maintain acceptable application performance under heavy loads. When physical memory becomes scarce and ESXi begins to use page swapping to meet the demand, Java application performance can be disproportionately affected as JVM garbage collections provoke spikes in page swapping. Oversizing heap memory allows the JVM to accumulate excess garbage, leading to increased garbage collection times as well as reducing the host's over-commit potential.
Administrators tend to over-provision VMs and JVM heaps to make sure there is always plenty of headroom. Headroom is a sensible precaution against large spikes, but significant over-provisioning of the heap or the VM can lead to considerable memory waste and much larger full GC pauses than with more modestly sized heaps.
The only way to really determine optimum vRAM and heap sizes is to observe what is happening on the host, in the VM, and in the JVM while applications execute under typical loads. To size VM and Java heap memory effectively, observe them over time to understand their behavior. Otherwise, resizing the VM or heap is a matter of trial and error.
The vSphere Client, the vSphere Web Client, and the various OS and ESXi monitoring utilities provide insight into ESXi memory utilization. However, it is difficult see what is happening within Java heap over time and the heap's relationship with vRAM.
The vSphere Web Client EM4J plug-in adds a Workloads tab to the vSphere Web Client to display information about the Java workloads on a VM and a historical graph of VM memory usage, including heap memory. The graph shows how efficiently the memory is used and highlights potential configuration problems.