"I claim that "Linux swap to real DASD is good for one thing, and that's to slow them down" From your post I understand that is your approach to tuning."
No, that's not true. My approach is not to hurt the production systems, when a development, test, or service machine gets in trouble. In a shared environment you can't throttle paging for a particular machine. All I can do is limit its maximum size (guest size plus vdisk). The guest size is easy to determine its impact. Just bring the machine up, let it settle and watch the paging. Minor vdisk use, also isn't a problem. But when something goes off, and uses/abuses all the vdisk it can get, VM starts paging and all machines are impacted. Perhaps, this is a good reason to have separate LPARs. One for production Linux and the other for all the other Linux stuff. Being a VM bigot, that was a hard thing for me to say. <G> Try this little task: 1. Logon to MAINT 2. Def stor (to the size of your LPAR) 3. Run the following: /* use up storage */ a = 'a' do forever a = a || 'a' end See if any users complain about poor response time. If you have sufficient "extra" resources to handle it, great. But there will be a time when it would be a big impact. (really, you shouldn't run it) I guess part of the vdisk abuse problem, is how large each shop makes the vdisk. I use (unless otherwise needed) 16MB/ 32MB/ 64MB. That is 112 MB total, if being abused. Now that I'm in a 3 GB LPAR, I doubt it would ever be a problem. But when I was on a 1 GB LPAR that was actively paging and my vdisk (note, only one) was 250MB (after all, it is free). Of course, in the VM world, we had this problem ever since vdisk was introduced. Application programmers in a 16 MB CMS machine, grabbing 512 MB vdisk and abusing them. My little 256MB IBM 9121 was on its knees. And without a performance monitor, finding that it was a vdisk abuse problem was rather difficult. Tom Duerbusch THD Consulting >>> [EMAIL PROTECTED] 2/23/2007 3:30 PM >>> On 2/23/07, Tom Duerbusch <[EMAIL PROTECTED]> wrote: > In a memory constrained system, it may be better (definitely for > test/development systems) to have swap go to dasd. Then, you are only > impacting that machine. When you have a big impact on the paging > system, almost everyone (including production) can be impacted. I claim that "Linux swap to real DASD is good for one thing, and that's to slow them down" From your post I understand that is your approach to tuning. The sad part is that you slow them down all the time when they swap, also when enough resources available. To avoid that, you need to make the servers large enough that they normally don't swap... and so you become more memory constrained. <img src=death-spiral.gif> > Actually, Mark, we agree on the basics of vdisk/swap. But I have never > seen a paging system that couldn't be swamped. How many times have I > PEEKed a file, should have been 10,000 lines, but it was 1,000,000 lines > (or 10 million lines), and watch the paging system, deal with my error. If you really measured that your paging subsystem was holding you back there, then you should probably improve that. Properly configured, z/VM can page pretty heavy without hurting itself. Very likely that it was the spooling subsystem that held you back because we sip slowly on spool files. Rob -- Rob van der Heij Velocity Software, Inc http://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
