John,
IMHO You should try to stick with no paging even with memory object
sorting. Buy more memory if you need it at $8K/G on z9 it's cheap and
getting cheaper on z10 at $6K/G I think. If you are adding to your
above the bar exploitation and paging already that does not make sense
to me.
It may be overkill but I stick with a 1:1 space allocation in page space
to central storage. That means some of our LPARs have 80GB+ of page
space spread across many storage processors 0% used. Page space is cheap
compared to explaining how you lost production with a WAIT 03C because
you saved a few DASD volumes of page space that would not normally be
used. The idea you will ADD a page volume dynamically and resolve an
AUX STORAGE SHORTAGE won't work fast enough most of the time. If we
have blown out the paging subsystem here and not resolved the problem
Standalone dump and IPL is probably going to be the fastest recovery.
If you under invest in page space and don't consider insuring you get
enough bandwidth across multiple page data sets on multiple storage
processors it may not hurt till it kills you. You won't know you don't
have a robust enough paging configuration till things get all pear
shaped.
Remember you need to be able to absorb lots of pageable storage getting
paged out and do it quickly. Even developments LPARs here have 14 LOCAL
page data sets here. PAV helps but it is no substitute for sufficient
space and multiple channels and storage processors ready to absorb the
I/O spike.
Best Regards,
Sam Knutson, GEICO
System z Performance and Availability Management
mailto:[EMAIL PROTECTED]
(office) 301.986.3574
"Think big, act bold, start simple, grow fast..."
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Chase, John
Sent: Wednesday, March 12, 2008 12:58 PM
To: IBM-MAIN@bama.ua.edu
Subject: Paging Subsystem -- "Comfortable" Size and Configuration?
Hi, All,
In preparation for z/OS 1.9 we're re-evaluating our paging subsystem
configurations. Currently we're using the same size and configuration
carried forward from "time immemorial", mainly because it still "works":
Three (3) page datasets of 2,000 cylinders each, with one "in reserve"
(available for PAGEADD) on each LPAR.
Now we're looking at exploiting some of the newer "stuff" that uses
above-the-bar storage (DFSORT's Memory Object sorting, for starters),
and I believe our current sizing and configuration will prove inadequate
"sooner" rather than "later". Right now our Development/Test LPAR runs
on a z9BC, with 4GB central storage allocated. It does "light" to
"moderate" paging. We also run our "sandbox" there, but it's
substantially idle most of the time. The "primary" CF also lives on the
BC.
Production runs on a z9EC with 14GB central storage (the other 2GB are
allocated to the backup CF), and the same paging subsystem configuration
as above. This LPAR currently does NO paging, but is the image we
believe would benefit most from exploiting Memory Object sorting.
What would be a "comfortable" paging subsystem configuration, especially
for the Production LPAR, as to individual size and (especially) number
of page datasets?
TIA,
-jc-
====================
This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
