My ratio is about 2.6 that represents a large (proportionately) number of CMS users.
-----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Barton Robinson Sent: Tuesday, May 13, 2008 10:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Overcommit ratio My use of the term "over-commit" is more simple with the objective of setting a target that management understands. I don't include vdisk - that is a moving target based on tuning and workload, as is the use of CMM1. The way I like to use the term is much higher level that doesn't change based on workload. I would use (Defined Guest Storage) / (CENTRAL + EXPANDED) (and people that use MDC indiscriminately or vise versa need some perforance assistance, but that is part of the tuning) With this, I have the objective of managing to this target. So using CMM (1) to reduce storage and the use of VDISK increases storage is the tuning part. And then I have a measurement that is compareable across systems - especially important when virtual technologies are competing and other virtual platforms don't/can't overcommit. This is a serious measure of technology and tuning ability as well. With current problems in JAVA/Websphere, Domino and some other Tivoli applications, I've seen the overcommit ratio attainable drop considerably. I used to expect 3 to 7 attainable, now some installations are barely able to attain 1.5. This starts to make VMWARE where 1 is a good target look better - not in our best interest. And it gives me a measure of an installation's skill set (or ability to tune based on tools of course). It would be interesting to get the numbers as i've defined for installations. Using this measure, what do y'all run? MARCY WROTE: Well, only if the server uses them. If you have a 1.5G server and it is using 1.5 Gig of swap space in VDISK then it is an impact of 3G virtual, right? If you have a 1.5G server and it is not swapping, it's impact is 1.5G virtual. So maybe more like (sum (guest virtual storage sizes) + sum (*used* vdisk blocks) ) / central storage. Wouldn't that be pretty simliar to number of pages on DASD method? Expanded storage? Add it to central? Nothing's simple anymore :) Marcy Cortes Rob van der Heij wrote: > On Tue, May 13, 2008 at 6:02 AM, Robert J Brenneman <[EMAIL PROTECTED]> wrote: > > >>The problem will be when you've allocated huge vdisks for all your production >>systems based on the old "Swap = 2X main memory" ROT. In that example - >>you're basically tripling your overcommit ratio by including the vdisks. This >>also can have a large cost in terms of CP memory structures to manage those >>things. > > > I think you are confusing some things. In another universe there once > was a restriction of *max* twice the main memory as swap, but that was > with another operating system to start with. > > Linux needs swap space to allow over-commit within Linux itself. The > amount of swap space is determined by the applications you run and > their internal strategy to allocate virtual memory. That space is > normally not used by Linux. > > >>The current guidance is a smallish vdisk for high priority swap space, and a >>largish low priority real disk/minidisk for occasional use by badly behaved >>apps. Swapping to the vdisk is fine in normal operations, swapping to the >>real disk should be unusual and rare. > > > The unused swap disk should only be on real disk when you have no > monitoring set up. In that case when Linux does use it, things get so > slow that your users will call your manager to inform you about it. > > The VDISK for swap that is being used actively by Linux during peak > periods is completely different. That's your tuning knob to > differentiate between production and development servers, for example. > It reduces the idle footprint of the server at the expense of a small > overhead during the (less frequent) peak usage. That tuning determines > the application latency and paging requirements. > > I believe the "over-commit ratio" is a very simplified view of z/VM > memory management. It does not get much better by adding other > factors. Just use the sum of virtual machine and VDISK. And remember > to subtract any other things like MDC from your available main > storage. > > Rob
