Memory health check

This article is part of the VMware vSphere Health Check PowerPack. More info can be found here: VMware vSphere Health Check PowerPack


VMs with Active Swap or Active ballooning

This check shows if any VM is having memory problems and indirectly also tells you about host memory availability. When a VM starts using its ballooning driver this in most, but not all, cases is because the host is running out of physical memory and is trying to free-up unused memory from within VMs that aren’t really using this memory. The memory that is freed by using the ballooning driver can be used by other VMs that are in need of more physical host memory. If the host has tried freeing memory by using the ballooning driver but still has a physical memory shortage, the host will start swapping VM memory to disk (VM swap file). Since the disk is very slow compared to physical memory, reading VM memory from swap is also very slow and therefore is a situation you want to avoid.VMware vSphere Memory Health Check

When this memory check sees VMs with active ballooning but no swapping yet, a “warning” is displayed in the check column. When there is active swapping on a VM, an “alert” is displayed in the check column. Seeing these warnings and alerts should trigger you to check the amount of free memory on the hosts in the cluster of this VM. When you hosts have enough free memory you can clear the swap of the VM by shutting down the VM and then power on again. A reboot of the guest OS is not enough to clear the swap.

Note: Although host memory shortage is the most common issue for swapping to occur, there can be other reasons as well. For example setting a memory limit on a VM lower than the amount of assigned RAM for the VM, will cause ballooning and swapping even though there is enough free host memory.


Service Console Memory for ESX hosts (non-ESXi)

On VMware ESX installs a fixed amount of RAM is assigned to the Service Console. This check shows you how much memory is assigned in this configuration.


ESX host memory usage and overcommit

Because of a very nice memory dedupe technique called Transparent Page Sharing (TPS) and having to only back the active memory of a VM with physical memory, a ESX / ESXi host can assign more memory to its VMs than really physically present in the host. This is no problem just as long as you know where the limits are.

This memory check shows you how much memory physical memory is present in each host. In the second column it shows the “Total Assigned Memory”. This is all memory that has been assigned to VMs running on this host and therefore the amount of memory these VMs could potentially use. The third column “Total Used Memory” shows how much physical RAM is really in use by these VMs. The difference between “Total Assigned Memory” and “Total Memory” (physical RAM) is the value in the fourth column: “OverCommit MB”. As long as the amount of “Total Used Memory” is lower than the total amount of physical RAM you should be safe. Even better, keep “Total Used Memory” around 15% less than the amount of physical RAM.

This check displays three possible values in the check column:

  • “OK” when you have assigned less RAM to VMs than physically available
  • “Good overcommit” when more RAM is assigned to VMs than physically available but the “Total Used Memory” is still below the amount of physical RAM.
  • “Bad overcommit” when more RAM is assigned to VMs than physically available AND the “Total Used Memory” is above the amount of physical RAM. You will probably also see swapping occurring at VMs in the previous check.

Reading tip: “Memory overcommit in production? YES YES YES