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 -- Rob van der Heij Velocity Software GmbH http://velocitysoftware.com/
