vRAM Vs. Physical RAM sizing

[Darkm]

Hello,

as I understand VMware has many RAM optimization features, so that we can use vRAM over commitment, which mean the amount of vRAM allocated can be higher than the physical RAM already installed on the server, I can find in some documents that 2:1 over commitment can be a good ratio, but I need to know if there are guidelines or tools to find out if over commitment will be ok , or we have to use 1:1 ratio ?

Thanks

Moamen

[mittim12]

I think it depends on what type of workload you are running.  If you are utilizing vSphere for Tier 1 apps like Exchange and SQL then you may not want to have any type of memory over commitment.   If you are simply running some web servers or application servers than over commitment may be ideal.  

[EdWilts]

This all depends on your guest configurations.  If your guests use 100% of their allocated memory, then you should aim towards the 1:1 ratio. If you typically configure guests with a lot of memory that normally goes unused, then you can work the overcommitment higher.

If you do overcommit, you have to carefully monitor ballooning and swapping and ensure that your guest applications are configured properly.  You may also need to pay more attention to guest memory reservations.  Some applications like Java and SQL, can behave VERY badly if you balloon and/or swap.

[golddiggie]

I typically just watch how the host reports actual memory usage as I'm adding more VM's to it. Right now I'm running eight VM's on the host in my home lab. Two of those are SQL servers, one is an Exchange 2010 server, and a mix of additional items. Of the 16GB of physical RAM in the host, it uses anywhere from around 10-12GB at any given moment. I like to keep under 75% host memory utilization, so I'm pretty much done for adding more VMs until I either add more RAM, or add another host (or change to a matching pair of hosts)...

I wouldn't think of it as a static relationship ratio, since it really does depend on what is installed on the VMs...

[wdroush1]

mittim12 wrote:

I think it depends on what type of workload you are running.  If you are utilizing vSphere for Tier 1 apps like Exchange and SQL then you may not want to have any type of memory over commitment.   If you are simply running some web servers or application servers than over commitment may be ideal.  

Also: you can mix and match using resource pools or just regular machine reservations. So your tier 1 can never overcommit, but lower tier stuff will.

[shishir08]

Lot depends on what kind of GOS you use and also the kind workload you are going to run inside the GOS.If the GOS is the same in all VMs then because of Transparent Page sharing you will be able to save a lot of memory.What I would suggest you is that over-commit till the point  your VM performance do not degrades and do not start using ballooning and swapping. you can use esxtop to monitor the stats of swapping and ballooning.

[Darkm]

Thanks all for your reply , it is really helpful , my last comment that I’m concerned when I will buy the Vsphere5 license, at this point I should decide how much vRAM I need so I can select the license type and quantity , assuming that I have a server with 64G RAM , and I will run 20 VMs and the vRAM needed for VMs based on the application to be total 80G RAM , so in this case I should buy the license to support 80G vRAM or more, but how I can know that over commitment will work?, as per your advice , I need to work with this setup and test , then to add more physical RAM if needed, is that correct ?

Thanks & BR

<http://www.bmbgroup.com/>

Lebanon I Egypt I KSA I Libya I Jordan I UAE I Algeria I Syria

Moamen Elhefnawy I System Engineers &Technical Operation Manager I CCIE 20582

8 Fathy Talaat Street I Square 1145I Sheraton Building - Heliopolis I Cairo , Egypt I Tel: +202 22685211 I Fax: +202 22685231 I Mob: +2018 6777711 I www.bmbgroup.com<http://www.bmbgroup.com/

[shishir08]

Yes ,you got it right.Just check with the current setup and if you find that performance is upto the mark then no need to add any extra RAM.

[wdroush1]

Darkm wrote:

Thanks all for your reply , it is really helpful , my last comment that I’m concerned when I will buy the Vsphere5 license, at this point I should decide how much vRAM I need so I can select the license type and quantity , assuming that I have a server with 64G RAM , and I will run 20 VMs and the vRAM needed for VMs based on the application to be total 80G RAM , so in this case I should buy the license to support 80G vRAM or more, but how I can know that over commitment will work?,  as per your advice , I need to work with this setup and test , then to add more physical RAM if needed, is that correct ?

Thanks & BR

cid:image001.jpg@01CC7E9F.49A2AF00<http://www.bmbgroup.com/>

Lebanon I Egypt I KSA I Libya I Jordan I UAE I Algeria I Syria

Moamen Elhefnawy I System Engineers &Technical Operation Manager I CCIE 20582

8 Fathy Talaat Street I Square 1145I Sheraton Building - Heliopolis I Cairo , Egypt I Tel: +202 22685211 I Fax: +202 22685231  I Mob: +2018 6777711 I www.bmbgroup.com<;http://www.bmbgroup.com/

That is really the fun part of the new vRAM licensing: when you're paying for vRAM you might as well take the plunge and back it with physical RAM, because you could be paying fo an additional 16GB of RAM, and suddenly VMs are ballooning because you have a specific workload or a tightly configured set of VMs, and now 16GB of vRAM you can't even use. Especially being as VMWare wanted us to "rightsize" all of our VMs, memory contention immediately means ballooning a tightly configured VM, and ballooning a "rightsized" VM means you're paging, not clearing various OS caches, bleh.

There are very small circumstances that it's even somewhat useful, but at $32/GB (more expensive than physical RAM) those vRAM licenses are worth backing with real RAM.

[rlund]

Just as a note, it doesn't prevent you from using more vRAM, it just tells you your usage and what you need to true up to.

Roger lund

vexpert

Vmug leader

[wdroush1]

Roger Lund wrote:

Just as a note, it doesn't prevent you from using more vRAM, it just tells you your usage and what you need to true up to.

Roger lund

vexpert

Vmug leader

Which is pretty much like running Windows AD with 5 CALs, or MSDN in production, or various other terrible license agreement violations that pretty much are akin to piracy.

[DSTAVERT]

Which is pretty much like running Windows AD with 5 CALs, or MSDN in production, or various other terrible license agreement violations that pretty much are akin to piracy.

It's actually not. The vRAM limits are soft so that a temporary spike or a short term need isn't going to cause loss of functionality. Yes it is your responsibility to anti up if the need goes beyond temporary. Having a soft limit allows you to right size through experimentation over time rather than having to over purchase in the beginning.

[wdroush1]

DSTAVERT wrote:

Which is pretty much like running Windows AD with 5 CALs, or MSDN in production, or various other terrible license agreement violations that pretty much are akin to piracy.

It's actually not. The vRAM limits are soft so that a temporary spike or a short term need isn't going to cause loss of functionality. Yes it is your responsibility to anti up if the need goes beyond temporary. Having a soft limit allows you to right size through experimentation over time rather than having to over purchase in the beginning.

They're "soft" in the sense of vCenter enforcement, but violation of that quota is still a violation of the licensing terms (average of 365 days). Unless you're cycling your RAM hungry VMs off and on (it's based on configured vRAM, not usage), if you're planning on going over, you're staying over.

[rlund]

All i indicated is that it is metered and you buy within accordance.