Memory swapping is a last resort measure used by VMware after memory ballooning resources have been fully utilized. It is used to operate Oracle VMware and SQL VMware virtual machines when there is insufficient memory to run them simultaneously. It is method of last resort because it nearly always creates performance issues the memory of the VMs that are being swapped. The additional overhead required for swapping can also cause problems for other VMs that aren't affected by the memory swap.
Definition
A high swap rate clearly indicates a lack of memory and the existence of associated Oracle VMware and SQL Server VMware performance issues. Swapping's primary cause is over-commitment due to high active memory demand of VMs. The occurrence of memory swapping can be roughly predicted by:
- Total Active Memory > (Capacity - Overhead) + Balloon-able memory + Page sharing savings
This shows, as stated before, that even with the positive effects of VMware ballooning and page sharing accounted for, a host will have to resort to swapping when VMs exceed available memory. Memory swapping may be caused by the following conditions:
- Excessive memory over-commit
When this occurs memory over-commitment exceeds the combination of memory capacity, VM memory allocation, VM workload. Not only do these factor create VMware performance issues, but so does the extra memory overhead required when utilizing memory over-commit. - Memory over-commit with memory
reservations
Memory reservation reduces the total amount of balloon-able memory. Putting aside a large portion of a host's memory for reservations may necessitate memory swaps of other VMs. Even VMs that are not actively using their reserved memory may be affected. - Disabled or not running balloon drivers
Balloon drivers that are not running, or have been disabled, will result in decreased balloon-able memory for the host. This may result in memory swapping even if there is available memory.
Occasionally when errors occur during the installation of VMware tools, their status will appear OK despite the VMware balloon driver not running. The best way to know if the balloon driver is running is through esxtop. Follow these steps:
- Go to the host and open esxtop or resxtop
- Got to the Memory screen and add the MCTL fields
- Locate the MCTL? field. If it contains N for any VM, then the balloon driver isn't running
Note: The balloon driver should never be intentionally disabled in a VM. It is a critical part of the proper operation of the VMware ESX memory management system. Doing so may result in unforeseen VMware performance issues; furthermore, it makes locating and repairing such memory problems very difficult.
Solutions
There are four solutions to performance problems caused by VM Memory Swapping:
Reducing Memory Over-Commitment
Reducing the levels of memory over-commit is usually enough to determine an approach for eliminating swapping on a VMware ESX host. Follow these stops to reduce memory over-commit:
- Adding physical memory to the host
This reduces the total level of memory over-commit. It may also reduce or eliminate memory pressure that necessitate the swapping in the first place. - Reducing the number of VMs running on the
host
This can be achieve by moving VMs to VMware ESX hosts with available memory. Begin by determining the memory usage of each VM as well as the available memory on the target host. Be sure that the migrated VMs don't create memory swapping to occur within the target hosts. The load be properly rebalanced only if vSphere's vMotion feature is configured. The migrated VMs and targeted hosts must also meet the requirements for vMotion. - Powering off non-critical VMs
Do this if additional VMware ESX hosts are not available. Doing so frees up additional memory resources available for critical applications. Remember that even essentially idle VMs consume some memory resources. - Adding the host to a DRS cluster
Like the previous solution, using DRS clusters to increase available memory frees up memory for VMs running on the affected host. Unlike the previous solution, rebalancing may be performed automatically. It then becomes unnecessary to manually prepare specific VMs to account for times of peak usage. - Maximizing page sharing
More memory may be made available by consolidating to the same server all VMs running the same OS, which results in increased efficiency from page sharing. Because the memory saved through page sharing depends on changing workloads on the VMs, it is not a reliable alternative to swapping.
Enabling the VMware balloon driver in all VMs
The VMware balloon driver should be enabled in all VMs in order to maximize Oracle VMware and SQL Server VMware's ability to recover idle memory. There should be no exception and be done irrespective to other solutions being utilized. VMs with critical memory needs should be protected by reservations and other resource controls to ensure that they receive their required memory allocations. Despite its importance the balloon driver can only delay the necessity of swapping in cases of excessive memory over-commit. Steps to reduce memory over-commit should be take as well.
Reducing memory reservations
Always re-evaluate a system's need for memory reservations. If they are causing the host to swap memory from non-reserved VMs, then you may want to remove them to reduce potential performance issues. In cases where a VM with memory reservations is not using its full reservation, then you should consider removing the reservation. If you cannot reduce or remove the reservations, then you must find ways to reduce memory over-commit.
Dedicating memory to critical VMs with resource controls
Memory reservations may be used to prevent swapping memory from performance critical VMs, but only as a matter of last result and only when it isn't possible to reduce the level of memory over-commit. Ultimately, this will only transfer swapping issues to other VMs, which will require their solutions to avoid severe performance degradation. While the memory may be reserved, performance on VMs with reservations may still be impacted by the increased disk traffic and memory management necessary required to honor the reservations.
Confio IgniteVM
Confio IgniteVM helps identify the impact of VM Memory Swapping for sites running Oracle on VMware, SQL Server on VMware, and other virtual databases. IgniteVM helps DBAs maintain performance and availability on virtual servers. IgniteVM is the only virtualization-aware database monitoring solution.
Learn more about IgniteVM solutions for:
Follow Us