Memory differs from CPU as it is a form of storage. Unlike CPU, which executes instructions as they enter it, memory keeps information for a much longer period of time. We are comparing nanoseconds to seconds (or longer, up to months, depending on the uptime of your VM). Information is stored in memory in standard block sizes, typically 4 KB or 2 MB. Each block is called a page. At the lowest level, the memory pages are just a series of zeroes and ones.

Keeping this concept in mind is useful as you review the memory counters. Memory has a very different nature compared to CPU, and the storage nature of memory is the reason why memory monitoring is more challenging than CPU monitoring.

Before you proceed with this section, you need to be familiar with vSphere memory management. The whitepaper at https://www.vmware.com/resources/techresources/10206 provides a good explanation. It is based on vSphere 5.0, but is still relevant in vSphere 6.0 Update 1. The only difference is the introduction of reliable memory technology in vSphere 5.5, which does not consume a lot of RAM because it is only for the vmkernel.

Many useful things about monitoring are shared in the paper, especially the fact that the hypervisor does not have direct visibility inside the Guest OS. When a Guest OS frees up a memory page, it normally just updates its list of free memory; it does not release it. This list is not exposed to the hypervisor, and so the physical page remains claimed by the VM. This is why the Consumed counter in vCenter remains high when the Active counter has long dropped. Because the hypervisor has no visibility into the Guest OS, you may need to deploy an agent to get visibility into your application. You should monitor both at the Guest OS level (for example, Windows and Red Hat) and at the application level (for example, MS SQL Server and Oracle). Check whether there is excessive paging or the Guest OS experiences a hard page fault. For Windows, you can use tools such as pfmon, a page fault monitor.

It is acceptable for an application to release memory that it does not use, and a well-behaved application will listen to the requests of the Guest OS to release inactive pages. It is advisable to discuss the performance impact of releasing unused memory with the application architect.

Another reason for deploying an agent is the Active counter itself. The vSphere manual says that it tracks the amount of memory that is actively used, as estimated by vmkernel based on recently-touched memory pages. In summary, the ESXi host periodically checks a sample of all the consumed pages of the VM and determines the Active counter's percentage. ESXi will assume that the sample is representative and derive the Active value for the VM as a whole. As a result, using Active in isolation can lead to sizing that is too aggressive or too conservative.

We will cover the metrics in more detail when we cover VM memory utilization counters later in this chapter.

There are certainly situations where you cannot deploy an agent. For example, in a large environment, it is common that the infrastructure team does not even have read access to the Guest OS, let alone permission to install an agent. You do not know what is running inside the Guest OS and yet you get a call if there is an issue.

In this situation, you can get some visibility if you put the pagefile into a virtual disk by itself. The entire VMDK only contains the swap partition with no temporary directory or other purpose. You can then use the virtual disk I/O counters to track swap activity, as memory read/write becomes disk read/write.

You should also check out the following sections in the VMware vSphere 6.0 Documentation Center:

As of early 2016, 256 GB of RAM on a two-socket ESXi host is becoming common. Assuming 16 GB is being used by the hypervisor and hypervisor-based services (antivirus, firewall, load balancer, distributed router, and Virtual SAN), that still leaves plenty of RAM for around 25-50 VMs per host (depending upon the size of the VMs). 50 VMs per host is probably the upper limit you want to place for server VMs before concentration consolidation risk becomes a real issue that you will need to answer for to your customer.

In tier 1 (the highest tier), the number of VMs per host is likely a lot lower. For VDI, the number can be higher because each desktop VM is likely configured with just 6 GB vRAM, they have many common pages (transparent page sharing), and users are not active most of the time.