The problem we face is 'paging creep'. Right after IPL, systems show 0% ASM usage for some period of time. Then usage starts to creep up until we get warnings, then eventually hit the no-more-SVC-dumps condition. Adding memory to an LPAR slows the creep but cannot seem to stop it altogether. The problem is most pronounced on systems with large DB2 apps.
Part of the problem, I learned some time back at SHARE, is that there is no mechanism to 'reclaim' page slots that no longer need to remain on disk. Once storage gets paged out, it sits there like a sandbag until the owning task is stopped. Contrast that with JES2 spool track reclaim, which constantly munches through spool like Pacman and frees up unneeded space. . . 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 Tom Conley Sent: Tuesday, April 11, 2017 11:13 AM To: [email protected] Subject: (External):Re: Paging subsystems in the era of bigass memory On 4/11/2017 1:16 PM, van der Grijn, Bart , B wrote: > Largest LPARs we have are about 200GB with 6 MOD27 per LPAR. They all run DB2 > for distributed workloads plus some application specific subsystems. > The two busiest of those LPARs each run one DB2 member of the same DB2 data > sharing group with a frame occupancy of about 39M. > Next to no paging. > > Bart > Bart, This is what has me puzzled. My two biggest users of AUX, according to TMONMVS, are our two DB2 production regions. They're like 90% of what's in the page datasets. I have the DB2 sysprog looking at DB2's virtual storage knobs to see if we have something misconfigured. Thanks, Tom Conley ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
