We have a totally different issue but I feel still related. I even opened a
service request with IBM, whom sent us off to the manuals and it as clear as
mud to read the fine manual, techdocs, etc. and get a precise answer. Our
problem is we have constrained ESQA/ECSA on one of our LPARs. We are a large
DB2 shop. Recent retirements and lost years of knowledge in this arena have
left those of us that remain scratching our heads.
Years ago Sam Knutson said something to the list to the effect of "DASD is
cheap so back up real 1:1", if I'm remembering it right. And we have been
doing that for many, many years in addition to adding IBM recommendations of
30% and having at least 3 local datasets (one techdoc mentions 5 min) whether
needed or not. Every time we have ever added real storage, we upped the number
of locals.
If we were to follow the 1:1 ratio now, we would be increasing ESQA even more.
For example: Our MAXSPACE=16000M and have allocated 512 G real memory. We
currently have 9 3390-27 local page datasets defined for that system. Our past
rule of thumb would suggest that 11 entire 3390-54 local page datasets are
actually required.
What we aren't sure of is if we are extremely oversized and can and should back
our current paging subsystem allocation down some to recover some of the ESQA
currently in use. Did I mention, we hardly, if ever, page? I know, that's a
good thing and if it ain't broke don't fix it but the ESQA issue really has us
looking at every little savings. How do I get a handle on what really is needed
when we increase real storage to ensure we: 1) don't constrain our virtual
storage any more, 2) continue successfully not paging, 3) understand why and
when we will need to up the sizing of our subsystem.
I'm glad I too was following this thread so that I was able to send our DB2
sysprogs the recommendation that Art Gutowski (THANK YOU!!) forwarded to the
group below to possibly help with our problem.
Appreciate any assistance anyone has or if anyone has ran into this situation
in the past. From reading and internet trolling, it looks like not many have a
handle on what it takes to get this right and is well, downright confusing.
Cheryl
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Jesse 1 Robinson
Sent: Thursday, April 13, 2017 3:27 PM
To: [email protected]
Subject: Re: Paging subsystems in the era of bigass memory
This thread did seem to morph into a focus on DB2, but the paging problem for
us is not confined to DB2. We have one utility system that was set up years ago
to be a 'CMC'. It's still dedicated to 'network stuff', which for some time has
narrowed down to CA-TPX, the SNA session manager. Very little else runs there.
Certainly no DB2 or CICS. Absolutely no end-user apps. We've sort of ignored
this system recently as we turned attention elsewhere. It was last IPLed in
January 2016, well over a year ago! It runs great except for this burr under
the saddle. The local volumes are all Mod-3. Whatever we decide to do about DB2
will not help here.
- IEE200I 11.29.28 DISPLAY ASM
- TYPE FULL STAT
- PLPA 100% FULL
- COMMON 36% OK
- LOCAL 53% OK
- LOCAL 49% OK
- LOCAL 43% OK
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
[email protected]
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Mike Schwab
Sent: Wednesday, April 12, 2017 8:18 PM
To: [email protected]
Subject: (External):Re: Paging subsystems in the era of bigass memory
Here is an IBM presentation on how to tune z/OS and DB2 memory, including some
parameters to set.
http://www.mdug.org/Presentations/Large%20Memory%20DB2%20Perf%20MDUG.pdf
On Wed, Apr 12, 2017 at 2:55 PM, Art Gutowski <[email protected]> wrote:
> Did someone on this thread say DB2??
>
> We have been experiencing similar AUX storage creep on our DB2 systems,
> particularly during LARGE reorgs (more of a gallop than a creep). Our DB2
> guys did some research, opened an ETR with IBM, and found this relic:
>
> Q:
> "[Why was] set realstorage_management to OFF when that zPARM was introduced
> in DB2 version 10?
>
> "Details
> "IBM z/OS implemented a Storage Management Design change after DB2 v10 was
> released.
> "• Before the design change, DB2 used KEEPREAL(NO), virtual storage
> pages were really (physically) freed, high CPU cost if YES
> DISCARDDATA KEEPREAL(NO), RSM has to get LPAR level serialization to
> manage those pages that are being freed immediately. That added to CPU
> usage and also caused some CPU spin at the LPAR level to get that
> serialization -- excerpt from PTF
>
> "To get around/minimize the impact of the original design shortcomings that
> was introduced by IBM RSM z/OS, setting zPARM realstorage_management to OFF,
> would probably have been prudent on most LPARs. HP/EDS tried to address this
> new issue IBM created.
>
> "IBM create two PTFs and changed the way DB2 and RSM manages the page frames.
>
> "• After a design change (now) DB2 uses KEEPREAL(YES), storage is only
> virtually freed
> "If DB2 doesn't tell RSM that it doesn't need a frame, then the frame
> will remain backed in real storage in some form. That causes the
> growth of real storage and paging and everything that goes with using
> up REAL storage. KEEPREAL(YES) allows DB2 to tell RSM that z/OS can
> steal the page if it needs it, but DB2 retains ownership of the page,
> and it remains backed with real storage. If z/OS needs the page, it
> can steal it -- excerpt from PTF
>
> "V10 APAR PM88804 APAR PM86862 and PM99575"
>
> So...perhaps check your DSNZPARM and make sure it's coded appropriately for
> more modern times. FYI, we are z/OS 2.2 and DB2 11.1, NFM. We are in the
> process of rolling out REALSTORAGE_MANAGEMENT=AUTO (the current IBM
> recommended setting) across our enterprise.
>
> HTH,
> Art Gutowski (with assist from Doug Drain, Steve Laufer and IBM)
> General Motors, LLC
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to [email protected] with the message: INFO IBM-MAIN
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
