A lot of the time, memory is the most constrained resource in a virtualised environment. There are a number of techniques that hypervisors employ to manage memory.
Virtualisation allows us to over commit memory, which improves utilisation, but can lead to other problems if not managed properly.
So, let’s start at the very beginning.
Memory Over-Commitment is a feature that allows a hypervisor to allocate more memory than the physical host actually has available. For example, if the host server has 2 GB of physical memory available, you can provision 4 virtual guest machines, each with 1 GB of memory allocated.
Usually, this is harmless, as most virtual machines only use a portion of their allocated memory. So in the example above, a Virtual Machine with 1 GB of memory allocated might only use 400 MB, so if all four machines have similar usage patterns, you will still have 400 MB of memory left over on the physical host.
Still, some VM’s might consume all (or even more) of their allocated memory. Alternatively, memory on the physical host might start to run out. In these cases, the hypervisor can identify and reallocate unused memory from other VM’s, using a technique called memory ballooning.
Memory Ballooning occurs when a host is running low on available physical memory. It involves the use of a driver – called the balloon driver – installed on the guest Operating System (OS).
So, how does this happen?
- Virtual Machine A needs memory, and the hypervisor has no more physical memory available.
- Virtual Machine B has some underutilized memory.
- The Balloon driver on VM B ‘inflates’ and this memory is now available to the hypervisor.
- The Hypervisor makes this memory balloon available to VM A.
- Once there is more physical memory available, the balloon on VM B ‘deflates’.
There is a huge advantage here – physical memory utilisation is more efficient, at the expense of potential performance problems. So far, so good.
This entire process is invisible to the guest operating system, however, it can possibly affect performance on the virtual machine. Excessive ballooning on the hypervisor (inflating and deflating) can impair performance of any applications running. An administrator troubleshooting and monitoring just the VM and the guest OS will not be able to pinpoint the root cause of the problem, much less fix it. Ballooning might manifest as high Disk I/O or latency. However, as you can see, the root cause is at the hypervisor level.
To avoid ballooning, you can create a ‘memory reservation’ for the virtual machine, guaranteeing an amount of physical memory. Ballooning can lead to swapping, another memory management technique.
Ballooning can lead to swapping at the hypervisor layer, however, swapping also occurs at the Guest OS level.
Guest OS Swapping
Memory Swapping is not unique to virtual environments, and comes from a time where physical memory (RAM) was extremely expensive.
Virtual memory is created on an attached disk, which emulates physical memory. When the CPU is trying to access virtual memory, the memory page is swapped into physical memory, where the CPU can access and manipulate it efficiently. Applications often access a small number of pages — the WORKING SET –frequently while using other pages sporadically or rarely. Swapping mechanisms typically keep the working-set in physical memory while other pages may be swapped to storage. Swapping increases the utilization of physical memory: frequently accessed pages reside mostly in physical memory, while infrequently accessed pages reside mostly in storage, not wasting physical storage.
This increase in utilisation comes at a cost – swapping slows down computations, as pages are read from/written or swapped between storage and/or physical memory. Storage is much slower than physical memory. This leads to performance degradation.
In order to assure performance, the physical memory has to be tuned, so that it matches the working set. Where the physical memory exceeds the working set, memory will be underutilised. However, if the working set is more than the physical memory available, excessive swapping occurs, resulting in inevitable performance problems.
The hypervisor is able to create swap space and keep memory pages there. Again, these memory pages emulate physical memory as far as the Virtual machines are concerned. So when the Guest OS is accessing this memory, the hypervisor has to swap the virtual pages into real physical pages. The complexity in this scenario occurs because the Guest OS is completely unaware of the entire process. All the VM’s residing on the hypervisor will start to experience performance problems, even those that do not perform a single swap. An administrator monitoring the Virtual Machine is oblivious to the root cause, unless he correlates the metrics from the guest with the hypervisor metrics.
Guest OS swapping is preferable to hypervisor swapping, as the Guest OS is at least aware of the process.
In order to realise the benefits of memory management, and avoid any issues that might arise, the techniques listed above need to be controlled carefully. This will be the subject of a future post.