On Sunday, 02/25/2007 at 08:33 ZE9, John Summerfield <[EMAIL PROTECTED]> wrote: > btw The rate of paging is fairly unimportant: in the 80s, we had an > Amdahl 4360 paging at 600 pages/sec. We looked at the numbers, we looked > at each other, we shrugged our shoulders: "TSO seems okay." > > Responsiveness and throughput are important. In our case, paging was > "fairly brisk" but overall balance seemed good (CPU was suitably busy too).
We've seen paging rates in the 10s of thousands of pages per second, so it doesn't bother CP to page as long as he has the resources to do it: Enough dedicated paging-only volumes, fast drives, fat pipes, multiple paths, balanced I/O. The performance measurement tools will tell you whether and how much you're waiting on the paging subsystem. So if it ain't broke, don't fix it. (Except to ensure multiple paths for availability.) Point: These tools can tell you what NOT to change, too, saving you time (and money). Except when you are just getting started, the "Crystal Ball Method of Performance Management" is not really dependable. And even then, it's only for those who have a real understanding of How Things Work. MY production system will have performance management software (whether from IBM or Velocity). MY PoC system will have the same thing, but with some PoC-level of support from the vendor. There's nothing like having your PoC go down the drain because there is a Performance Problem, and no one can figure it out. Or you get a CritSit going to get a SME in to solve the problem, but you still take it on the chin. "My <vendor> servers don't have that problem! Nyah!" Alan Altmark z/VM Development IBM Endicott ---------------------------------------------------------------------- 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
