Well, I like to see zero paging and, more than that, some spare real memory. What I don't much like to see is installations with tons of real memory and not exploiting it (where they could). For many the memory world changed with z10 and again subsequently...
Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: [email protected] Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: "Staller, Allan" <[email protected]> To: [email protected], Date: 11/09/2012 04:50 PM Subject: Re: Paging configuration recommandation on modern Dasd. Sent by: IBM Mainframe Discussion List <[email protected]> Are you sure? What ratio are you using for your sizing estimates? I have not read or found anything to refute my prior estimate, going back to MVS/ESA (ignoring ESTOR paging and SWAP which are now obsolete, and possibly paging above the bar). Yes the ASM algorithms have been updated to handle larger real storage sizes with less overhead, primarily by invoking the routines less frequently under low stress, however, the actual paging routines themselves have not been altered significantly with the exception of SUSPEND/RESUME removal and PAV support. I might budge on the PPS/Page dataset, but that's about it. Channel/Device/Control unit issues are smaller due to the advent of ESCON/FICON/PAV. A given is that particular set of workloads in an LPAR with X amount of real storage will produce a paging rate of Y. If the workload(virtual storage wise) is increased without a corresponding increase in real storage the paging rate will increase as the square of the ratio. Likewise, if real storage is removed without changing the workload, the same behavior will occur. <snip> For most installations your virtual-to-real ratio is way out of date. Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM </snip> <snip> The "optimum" VSTOR config is 2:1 virtual to real. I personally use 3:1 (RSTOR *3). This is a trade off between page rate and devices allocated. I.e. the sum of all working sets for the LPAR(in frames) is up to 3 times the number of real storage frames available. This paging rate goes up *VERY VERY* quickly after 3:1 IIRC, this is a SQUARE function. For a given original page rate: To go from 2:1 virtual/real to 3:1 virtual/real generates the ratio (9/4 * original page rate) 2.25 times To go from 2:1 virtual/real to 4:1 virtual/real generates the ratio (16/4 * original page rate) 4 times the original page rate. </snip> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
