3 Replies Latest reply on Jun 17, 2008 7:42 PM by qnetter

    Using overcommited memory?

    Master

      I just posted about a new blog post from VMware on this thread Cheap Hypervisors: A Fine Idea -- If You Can Afford Them. Eric Horschman talks about cost per VM and how memory overcommit lets you put more VMs per physical server on VI3 vs other hypervisors.

       

      If you think this is a valuable article, feel free to Digg It

       

      Although some vendors cough claim it's never useful in the real world, we beg to differ. If your VMs are happily using overcommitted memory, feel free to tell your story here or over there!

        • 1. Re: Using overcommited memory?
          jasonboche Champion
          vExpert

          Dugg it.

           

          To address memory overcommit (no pun intended), I would like to offer up a quick case study where memory overcommit works in my company of 160,000 employees.  A few weeks ago I begain posting preliminary analysis of running production Citrix Presentation Servers inside VMs on ESX 3.x (see http://communities.vmware.com/message/863920).  My preliminary findings show that the production Citrix VMs are taking advantage of Content Based Page Sharing (for a detailed explanation of VMware's Content Based Page Sharing, see Carl Waldspurger's whitepaper on Memory Resource Management in VMware ESX Server at http://www.waldspurger.org/carl/papers/esx-mem-osdi02.pdf).  One virtualized Citrix server is handling 50-85 sessions and it's not full yet.  Each of the sessions is running one of three published applications that all share the same base PowerBuilder code and .DLLs (about an 80MB memory footprint for each session).  Because each of the 50-85 sessions shares the same code, the VMware's Content Based Page Sharing consolidates many of the identical pages into single read only reference points and discards the redundant copies.  The net result is significant ESX host memory savings.  As an example, what I'm seeing inside the Citrix VM is nearly 4GB of RAM being used, but from the ESX host perspective, 1GB or less physical RAM is being utilized, leaving the additional 3GB of physical RAM for another VM in the cluster to use.  Now multiply this memory savings by the number of virtualized Citrix servers and the memory savings adds up quickly.

           

          In the blog banter, a point is made by the opposition that it's going to be rare for a number of VMs on the same host to all be identical such that there would be a significant savings in memory page sharing.  My example is proof that you don't even need multipe VMs to take advantage of VMware's page sharing and memory overcommit.  The fact is that VMware's Content Based Page Sharing works both inter-VM (across VMs) and intra-VM (within a single VM).  I verified this with Carl Waldspurger himself a few weeks ago.  Summary:  Citrix VMs running silo'd or partitioned application sets take advantage of intra-VM Content Based Page Sharing.

           

          On the inter-VM Content Based Page Sharing front, an assumption is made by the opposition that rarely will VMs share the same code to amount to any sort of memory savings.  I don't have hard numbers yet but I will say that in our VDI deployment that we are rolling out, all Windows XP images are rolled out from the same template which contains all of the tools each VDI user needs to do business.  While there is no guarantee each VDI user will concurrently be running the same applications within their VDI, it's a fact that at a minimum they will each be running the same base operating system (Windows XP), Microsoft Outlook plus all of the MS Office code that loads in the background and at startup.  Most will probably have at least 1 IE browser open as well, although the IE footprint is fairly minimal in the grand scheme of things.  Depending on the number of virtual desktops we deploy on each host, I think we'll see generous memory savings.  This is not to say we will intentionally overcommit memory.  Ballooning and VMKernel swap allows memory overcommit but I'm not that desperate to take the performance hit that comes with it, although I'm not sure whether or not our VDI users would be able to tell the difference or not.

           

          Jas

           

           

           






          [i]Jason Boche[/i]

          [VMware Communities User Moderator|http://communities.vmware.com/docs/DOC-2444][/i]

          • 2. Re: Using overcommited memory?
            Master

            Jason, thanks! Anybody else? I was talking with an SE last week, and he was telling me about a recent customer where the Windows group was happily using VMware, but the Linux group thought they should go with an open source solution, and besides they thought that memory overcommit would hurt performance. Well, some of their Linux boxes were already on VI3, and they quickly brought up VC and looked -- on some hosts it was as high as 20:1, and the lowest was 3:1, and all the workloads had great performance.

             

            So the point is not that you can't misconfigure memory overcommit, but that in many every day situations it can be incredibly useful to get consolidation ratios unheard of with other virtualization platforms. Other vendors are going to badmouth it just until they have it too.

             

            So what's your overcommit ratio?

            • 3. Re: Using overcommited memory?
              qnetter Novice

               

              "Each of the sessions is running one of three published applications that all share the same base PowerBuilder code and .DLLs (about an 80MB memory footprint for each session). Because each of the 50-85 sessions shares the same code, the VMware's Content Based Page Sharing consolidates many of the identical pages into single read only reference points and discards the redundant copies."

               

               

               

               

               

              Um, if they share the same base PowerBuilder code and DLLs -- which should be read-only pages -- doesn't Windows consolidate those pages into a single copy-on-write instance, with no involvement at all from the page sharing code?!