Hello, I think Rob's description really makes sense.
But another view to the swap problem - or should we say the problem of sharing real memory: Can't we live without swap at all and use the cooperative memory management technique? You just define enough real memory for each linux instance to handle every peak (well, maybe almost) and they just use what they really need and release everything else to the common memory pool. You don't have to save free memory for new linux instances - all the memory which is free above VM for linuxes can be defined for them and they share it dynamically in the most effective way. I have not implemented this yet, but looking forward to do that. Am i too enthusiastic? CMM _must_ have a problematics of its own ... :) Juha Vuori Lindorff, Finland Rob van der Heij wrote: > On Thu, Nov 27, 2008 at 8:57 AM, Mark Post <[EMAIL PROTECTED]> wrote: > >> Back when that book was written (2000) that would have been a good >> recommendation. (By the way, for those of you that have the expurgated >> version, the chapter would be 9.3.4.3.) That was before we had the ability >> to create multiple partitions on DASD volumes, and real storage was even >> more expensive than it is today. These days, having your paging going to a >> swap file within a file system would be, as Rob likes to characterize it, >> good only for slowing your Linux system down. > > While my phrase "real disks for swap is only good for slowing down > Linux" was meant to look funny, there's a lot of truth in it. > It has been a while, so maybe I try to explain again (and apologize to > the rest for the long note) > > You need to distinguish between two different kinds of Linux swap > space. It is easy to get confused because they look the same in Linux > and z/VM. > 1. high performance swap space that is actually being used during peak > utilization of the Linux guest. You want this to be fast so that it > does not impact the guest performance. So it must not be real disk. > This is to *reduce* storage requirements for guests with low average > utilization (so the idea of not using VDISK because you are short of > real storage is a myth, and we have numbers to show). > 2. overflow swap space that is normally not being used, but just there > to let Linux overcommit resources and to help out when usage of the > guest goes way beyond the planned capacity (when you're being > slashdotted). Since it is not used, there is no I/O and I/O > performance does not matter. As long as you don't use it, VDISK is for > free* but real disk costs money. > > You can't do high performance swap in real disk. If you only have real > disk for swap then you don't have that first part and you have not > configured your servers to have their memory requirements follow the > workload. So you don't share white space memory. That may be right > when your applications are busy all the time and there is no white > space to share. Or you may have so much real memory that you don't > need to share. > > Now assume you use VDISK for your overflow capacity. When the Linux > application goes through its roof and starts to use the overflow swap > space, performance will not degrade because of that when you have > VDISK. But that VDISK is not for free anymore now that it is being > used. Even though you can't tell from your users complaining, you do > want to be aware that usage went beyond planned capacity and act on > it. > That's why you need to monitor this and alert responsible parties when > it happens. Depending on the cause, you increase the allocated > resources for the server, fix the application, etc. You may also need > to empty that overflow VDISK. > > But if you don't use a performance monitor, you need another way to > tell when usage goes beyond planned capacity. If you use real disk for > swap to slow down extremely, your users will inform you (often through > proper management chains) and give your successor a chance to adjust > the allocated capacity. ;-) > > :xmp type=sad. > A Dutch semi-government institution recently launched a previously > announced web service. It was closed down the next day because the > number of visitors turned out to be 10 times more than anticipated. > They plan to launch it again in 6 weeks when more resources are > allocated to the service. > :exmp. > > Recommendations like swap files between your real data come from > system administrators running Linux on non-virtualized platforms. In > such an environment you dedicate the resources upfront. When your > requirements go beyond the allocated capacity, you have no option but > re-use some resources that you already had. And when you have plenty > of unused CPU the longer code path may not be too much of a problem. > And with the swap partition being on the same device as your data, the > difference may be less significant. > Also, that is an environment where performance measurement is less > mature and "configuration by convenience" is more popular. I recently > ran into a system administrator who swapped into a logical volume > under LVM because he believed that was more flexible and easier to > oversee. > > Rob > -- > Rob van der Heij > Velocity Software > http://www.velocitysoftware.com/ > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
