Many of VMware’s customers use memory reservations during troubleshooting only in a final attempt to fix performance problems. It is true that memory reservations can limit ballooning and host swapping. But if you are only using reservations to anticipate and avoid memory bottlenecks, you are missing one of the great uses of the feature: memory reservations can drive over-commitment.
What do I mean by “drive over-commitment”? I mean that, when properly used, memory reservations allow a VI admin to optimally pack virtual machines across a cluster’s memory. With properly set reservations, an admin can continue to power on a cluster’s VMs until vCenter’s admission control refuses to allow more. At that point you can know that you the optimal number of virtual machines is on your hosts.
The first step in using vCenter’s admission control to drive consolidation is to properly reserve memory. You do this by summing the minimum memory needs for everything in the virtual machine and setting reservations to that number. Some thoughts on reservations follow:
|Memory Consumer||Amount of Memory||Comments|
|Operating system||200MB – 1 GB||Newer OSes tend to use more than older OSes, Windows tends to use more than Linux.|
|Application code (not user data)||50MB – 1GB||This number varies widely from application to application. Check with your ISV for the application’s needs.|
|Heap (user data)||0-255GB||I am generally calling the amount of user-specific data collected by a running application the “heap”. This applies to databases, Java applications, web server caches, etc. You should size this based on your application’s data set, usually aiming for a heap size of 2-10% of the total data size. Consult your ISV.|
This table will get you started in setting a virtual machine’s memory. For example, consider a virtual machine running Windows Server 2003 (500MB minimum), with SQL Server 2005 (500 MB), running a database that needs at least a 500 MB cache. This VM’s reservation should start at 1.5 GB. But for future growth, small spikes of peak usage, and for additional administrator tools, it is entirely possible that additional 2 GB will be needed. So, the VM should be sized to at least 3.5 GB with a 1.5 GB reservation.
Given the wide variation in memory usage from OS to OS, application to application, and instance to instance, I would by lying if I told you a formula worked right without later revision. The truth is you can only estimate these values before deployment. You will have to monitor your memory hungry applications and fine tune reservations over time.
You do this by checking vCenter’s stats for each VM’s active memory. The active memory should be less than your selected reservations except for rare occasions. So, if active memory is much higher than your reservations, increase reservations. If your VM is consistently using less memory than you have reserved, reduce the reservations.
When care has been taken to properly size and reserve memory, the administrator can power on virtual machines confidence that memory is available to support the application. When vCenter is unable to reserve enough memory to support your reservations, it will refuse to power on VMs. This means that memory management is no longer about trend analysis and capacity management. Instead you will investigate application needs with their owners and trust vCenter to give you a simple “yes” or “no”.