Memory overcommitment in production - could it be appropriate in this case?

[tostao]

Hi Folks,

I was given a specification for a number of virtual machines by an application architect a couple of months back.

2 x Red Hat 6, 64GB memory, 4 CPUs

2 x Red Hat 6, 32GB memory, 4 CPUs

These VM's used approximately 75% of my total cluster resources. I have monitored these VMs and it has been proven that these machines were outlandishly over spec'd. In actuality, the memory usage is no more than 1% of the allocated amount. For one of my hosts in the cluster I can see 1.5GB active out of 26.5GB consumed. Despite my protestations and sending on a steady stream of performance stats I have been unable to have these machines resized.

I am aware that VMware do not advise the use of overcommitment in a production environment. However, I am planning to overcommit the memory on my cluster (vSphere ESXi 4.1) to make the most of the wasted memory.

So I wanted to run this past you guys to see if I might be making any false assumptions on VMWare memory management. Are there certain conditions (like mine) which memory overcommit would be appropriate?

One final piece of information, at the moment none of the 4 systems have the Balloon Driver installed yet, the VMWare Tools were installed without it. However, I have convinced the admins to install the Balloon Driver by sending them information how the Balloon Driver prevents host swapping which itself can impact system performance.

Thanks,

Mick

[weinstein5]

Yes there are definitely situations where memory overcommittment is acceptable - from the information you provided it sounds like you have a case where it will make sense  but I do agree you should install the Balloon Driver as it ia one of the tools that ESXi can deploy ease memory contention as well it will give you window sto be able to respond if there is a situation where memory contention occurs -

[peetz · Accepted solution]

I agree with David and want to make you aware of an interesting opportunity: Once the baloon driver is installed in these VMs you will be able to force balooning on them by setting a RAM resource limit that is lower than the amount of configured RAM. That means e.g. you could limit the 32GB-VM to 24GB (or even less), and the baloon driver will steal the surplus of 8GB and return it to ESXi.

Of course in production you should use this method only as a last resort, but there is a chance that the VM admins will even never notice that. In the past I tried that with some heavily oversized Windows/Exchange servers that were in test status, and the admins were not aware of a problem until some day they really started to use the system ...

- Andreas

[JohnADCO]

We are over committed bad on some hosts and we have yet to see a performance issue from it.    Makes it so we can't afford to go to Version 5 though.

[tostao]

Thanks Guys.

To Peetz,

That's a really useful tip.

It's not the most honest approach but it gives me the opportunity of bypassing all the political nonsense.

Thanks,

Michael