Memory Overcommitment – What is it good for?

The statement, “there is no technical benefit to memory overcommitment” is usually met with universal scorn, righteous indignation and a healthy dose of boisterous laughter.  However, at second glance this statement is not quite so absurd. Overcommiting memory does not make your VMs faster, it doesn’t make them more highly available and it doesn’t make them more crash-resistant. So, what is memory overcommitment good for? The sole goal of memory overcommitment is to put more VMs per host.  This saves you money. Thus, the benefit that memory overcommitment provides is a financial benefit.

Are there other ways to attain this financial benefit?

Memory overcommitment is one of the main reasons people choose the ESX hypervisor.  If the goal of memory overcommitment is to save money and there are other ways to attain these cost savings on other hypervisors without utilizing memory overcommitment, does that change the hypervisor landscape at all?  Before delving into that question, let’s first see if there is a way to save as much money without using memory overcommitment.

One way around this I’ve heard suggested is to just increase the memory in your hosts.  So, if you had an ESX host with 10GB of memory and were 40% overcommitted then you could use XenServer or Hyper-V with the same amount of VMs but each host would have 14GB of memory.  This to me does not seem fair as you could also add 4GB more to your ESX host and achieve even more cost savings.  However, you can only add so much memory before becoming CPU-bound, right?  I’m not referring to CPU utilization but the amount of vCPU’s you can overcommit before running into high CPU Ready times.  Let’s use my earlier example.  You have 14, 1 CPU/1GB VMs on a 4CPU/10GB ESX host.  You want to put more VMs per host so you increase your host memory to 20GB.  You now try putting 28, 1CPU/1GB VMs on the host.  This is now twice the amount of vCPUs to the same amount of pCPUs and let’s say your CPU Ready times are around 5%-10%.  Adding more VMs to this host, regardless of how much more memory slots you have available, would adversely impact performance, so you have a ceiling of around 28 VMs per host.

Knowing this number, couldn’t you then size your hosts for 4CPU and 30GB of RAM on XenServer or Hyper-V and then be saving just as much money as ESX?  And this is only one way to recoup the financial benefits overcommitment provides you.  If you already have Windows or Citrix products you might already own these hypervisors from a license perspective and it might not save you money to go out and buy another hypervisor. Also, some hypervisors (like XenServer) are licensed by server count and not socket count (like ESX) so you could potentially save a lot of money by using these hypervisors.  In any of these cases, an in depth analysis of your specific environment will have to be done to insure you’re making the most cost effective decision.

Of course, memory overcommitment is not the only reason you choose a hypervisor.  There are many other factors that still have to be considered.  But given this discussion, is memory overcommitment one of these considerations?  I think once you realize what memory overcommitment is really good for, it becomes less of a factor in your overall decision making process.  Does this realization change the hypervisor landscape at all?  As I mentioned earlier, memory overcommitment is a major sell for ESX.  If you can attain the financial benefit of memory overcommitment without overcommiting memory then I think this does take a bite out of the VMware marketing machine.  That said, ESX is still the #1 hypervisor out there in my opinion and I would recommend it for the vast majority of workloads but not necessarily because of memory overcommitment.  There is room for other hypervisors in the datacenter and once people realize what memory overcommitment “is” and what it “isn’t” and really start analyzing the financial impact of their hypervisor choices I think you’ll see some of these other hypervisors grabbing more market share.

Thoughts?  Rebuttals?  Counterpoints?

, , , ,

  1. #1 by Todd Deshane on March 24, 2011 - 9:46 am

    I think you should also mention the dangers of memory overcommittment. For example, it can lead to swapping and very poor performance. Memory overcommittment across a pool of servers could help mitigate this, but I wonder if this is used in practice?

    It seems that overcommit might not be for all workloads too (for example

    Also, I’d like to hear your reasoning for saying VMware ESX is the best hypervisor.

    • #2 by speakvirtual on March 24, 2011 - 2:00 pm

      Thanks for the feedback. In my previous post I did allude to swapping leading to poor performance so I didn’t think it was worth re-hashing again. Memory overcommitment across a pool of servers is the norm I would say. Automatic live migration (DRS/Work Load Balancing) is another technique that makes memory overcommitment even more feasible in that type of environment. Any technology improperly managed can lead to poor performance, in my opinion. If you design the environment properly and have controls on how new VMs are moved into and out of your systems then memory overcommitment shouldn’t be a problem and swapping should be extremely rare. I think it’s analogous to technologies like storage thin-provisioning, if you manage it improperly then bad things are going to happen in that environment (running out of disk space), but manage it properly and it can save you a good amount of money. And that was the point of the post, memory overcommitment is good for saving you money, however, you can get the same cost savings if not more without overcommitment on other hypervisors.

      Why do I think ESX is the best hypervisor? I think it’s the overall best hypervisor for most workloads because of ease of management, feature set and there’s something to be said for being the most “mature” hypervisor; other vendors will develop products that will integrate with your hypervisor first. An example of “ease of management” would be the vSphere Client vs. XenCenter. Anyone who has used both of these products can see that the vSphere Client is a much more robust product that gives you MUCH more information about your infrastructure and is easier to manage. The performance graphs are way better, you can do most things in the GUI without having to use the CLI, etc., etc. As far as features, a few I can think of would be Storage vMotioning, Storage IO control, “Fault Tolerance”, etc. There are more but those are a few examples. And when I talk about vendor integration, a few examples would be vKernel, Vizioncore, Veeam, etc.

      Now, you may not need these features for some workloads. I think XenApp and VDI are two examples of workloads that could be managed by other hypervisors. ESX to me is the “one size fits all” hypervisor. Sort of the “Microsoft Windows” of the hypervisor world. It’s the best for most workloads but not all and to reiterate, the financial benefits memory overcommitment gets you could be gained without overcommitment on other hypervisors. That was much longer than I intended but I hope I addressed all your points. 🙂

Leave a Reply to speakvirtual Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: