Information Technology Reference
In-Depth Information
In these sorts of env ironments, it's generally safe to overcommit memor y by as much as 50 percent
of the physical RAM installed in the server without seeing noticeable performance degradation.
h is means a server with 32 GB of RAM could potentially host VMs confi gured to use 48 GB of RAM.
Larger overcommitment ratios are certainly very possible, particularly in VDI or virtual desktop
environments where a large number of VMs are using the same base OS image. We've seen certain
environments where TPS alone provided upwards of 90 percent memory savings. However, the
key to wisely using memory overcommitment to maximize the value of your vSphere deployment
is knowing the needs of the VMs and how they consume resources.
Using Memory Limits
If you refer back to Figure 11.3, you will also see a setting for a memory limit. By default, all
new VMs are created without a limit, which means that the initial RAM you assigned to it dur-
ing creation is its effective limit. So, what exactly is the purpose of the Limit setting? It sets the
actual limit on how much physical RAM may be utilized by that VM.
To see this behavior in action, let's now change the limit on this VM from the default setting
of Unlimited to 2,048 MB.
So, what is the effective result of this coni guration? Here's how it breaks down:
The VM is coni gured with 4,096 MB of RAM, so the guest OS running inside that VM
believes that it has 4,096 MB of RAM available to use.
◆
The VM has a reservation of 1,024 MB of RAM, which means that the ESXi host
must
allo-
cate 1,024 MB of physical RAM to the VM. This RAM is guaranteed to this VM.
◆
Assuming the ESXi host has enough physical RAM installed and available, the hypervi-
sor will allocate memory to the VM as needed up to 2,048 MB (the limit). Upon reaching
2,048 MB, the balloon driver kicks in to prevent the guest OS from using any more memory
beyond 2,048 MB. When the guest OS's memory demands drop below 2,048 MB, the bal-
loon driver del ates and returns memory to the guest. The effective result of this behavior
is that the memory the guest OS uses remains below 2,048 MB (the limit).
◆
The 1,024 MB “gap” between the reservation and the limit could be supplied by either phys-
ical RAM or VMkernel swap space. ESXi will allocate physical RAM if it is available.
◆
The key problem with memory limits is that they are enforced without any guest OS aware-
ness. If you have a VM coni gured for 4 GB of RAM, the guest OS inside that VM is going to
think it has 4 GB of RAM with which to work, and it will behave accordingly. If you then place a
2 GB limit on that VM, the VMkernel will enforce that the VM only uses 2 GB of RAM. Fine—but
it will do so without the knowledge or cooperation of the guest OS inside that VM. The guest OS
will continue to behave as if it has 4 GB of RAM, completely unaware of the limit that has been
placed on it by the hypervisor. If the working set size of the guest OS and its applications exceeds
the memory limit, setting a limit will degrade the performance of the VM because the guest OS
will constantly be forced to swap pages to disk (guest OS swapping, not hypervisor swapping).
