Have you got RMF3? Tried looking at STORF to see what address space(s) are consuming all your AUX slots?
Are you running Netview? Got a CANZLOG dataspace? That can chew through a lot of memory if not configured quite right in recent z/OS releases. On 13 April 2017 at 20:26, Jesse 1 Robinson <jesse1.robin...@sce.com> wrote: > 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 > robin...@sce.com > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Mike Schwab > Sent: Wednesday, April 12, 2017 8:18 PM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 <arthur.gutow...@gm.com> > 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 lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
