Re: Paging subsystems in the era of bigass memory

z/OS MVS Initialization and Tuning Guide: Because SCM does not support persistence of data across IPLs, VIO data can only be paged out to DASD. Therefore, even when SCM is installed you must still maintain a minimum amount of storage that supports paging for all of your VIO data, and a minimum

Re: Paging subsystems in the era of bigass memory

~lynn/2017d.html#60 Optimizing the Hard Disk Directly recent paging subsystem posts here http://www.garlic.com/~lynn/2017d.html#58 Paging subsystems in the era of bigass memory http://www.garlic.com/~lynn/2017d.html#61 Paging subsystems in the era of bigass memory http://www.garlic.com/~lynn/201

Re: Paging subsystems in the era of bigass memory

And if the buffer page is paged out to SCM, it should be faster to read it from SCM than from the DB2 data set. But if it is paged out to a page data set, it might be faster to read it from the DB2 data set, because DB2 (via Media Manager) uses zHPF, but z/OS has not been enhanced to use

Re: Paging subsystems in the era of bigass memory

On Tue, 18 Apr 2017 00:47:55 -0500, Barbara Nitz wrote: >>I don't want to turn this into a debugging session, but this is what I see in >>RMF3 on the non-DB2 utility system. >>All of the TPX 'regions' are below this list sorted by Aux Slots. No task >>shows any page-ins. >

Re: Paging subsystems in the era of bigass memory

> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Greg Dyck > Sent: 18 April, 2017 15:58 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Paging subsystems in the era of bigass memory > > On 4/18/2017 2:25

Re: Paging subsystems in the era of bigass memory

On 4/18/2017 2:25 AM, Vernooij, Kees - KLM , ITOPT1 wrote: As I said, I remember reading this a long time ago, I don't know the details anymore, whether the source was reliable and whether it is still working this way. Only a DB2 internal expert should be able to tell. ... On 12 April 2017

Re: Paging subsystems in the era of bigass memory

; From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Tony Harminc > Sent: 12 April, 2017 18:45 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Paging subsystems in the era of bigass memory > > On 12 April 2017 at 10:16, Tom Marchant < &g

Re: Paging subsystems in the era of bigass memory

>I don't want to turn this into a debugging session, but this is what I see in >RMF3 on the non-DB2 utility system. >All of the TPX 'regions' are below this list sorted by Aux Slots. No task >shows any page-ins. Not sure that you haven't already done this: Use IPCS active on that system, and

Re: Paging subsystems in the era of bigass memory

> 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 i

Re: Paging subsystems in the era of bigass memory

-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

Re: Paging subsystems in the era of bigass memory

Just check with our DB2 SYSPROG, same here. Carmen - Original Message - From: "Mike Schwab" <mike.a.sch...@gmail.com> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, April 12, 2017 10:18:22 PM Subject: Re: Paging subsystems in the era of bigass memory Here is an

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 wrote: > Did someone on this thread say DB2?? > > We

Re: EXTERNAL: Re: Paging subsystems in the era of bigass memory

.EDU] On Behalf Of Carmen Vitullo Sent: Wednesday, April 12, 2017 1:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL: Re: Paging subsystems in the era of bigass memory Yes, and Thank you Art for that - I've passed this info on to our DB2 SYSPROG Carmen - Original Message - From:

Re: Paging subsystems in the era of bigass memory

Yes, and Thank you Art for that - I've passed this info on to our DB2 SYSPROG Carmen - Original Message - From: "Art Gutowski" <arthur.gutow...@gm.com> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, April 12, 2017 2:55:53 PM Subject: Re: Paging subsystems in t

Re: Paging subsystems in the era of bigass memory

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

Re: Paging subsystems in the era of bigass memory

The topic seems to of morphed from Do I need to acheive a 30% page dataset utilization from virtual storage stable LPAR with a single large DB2 to Running many DB2s in a single LPAR I seem to have a memory leak that requires periodic IPLs to avoid an aux storage problem other than some common

Re: Paging subsystems in the era of bigass memory

what to do? add some more locals? NO! Carmen - Original Message - From: "Jesse 1 Robinson" <jesse1.robin...@sce.com> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, April 12, 2017 12:56:19 PM Subject: Re: Paging subsystems in the era of bigass memory

Re: Paging subsystems in the era of bigass memory

Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Wednesday, April 12, 2017 10:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Paging subsystems in the era of bigass memory On Wed, 12 Apr 2017 12:44:32 -0400, Tony Harminc wrote: >On 12 April 2

Re: Paging subsystems in the era of bigass memory

/www.garlic.com/~lynn/subtopic.html#hone other trivia: the stanford thesis advisor went on to be president of stanford past posts in this thread: http://www.garlic.com/~lynn/2017d.html#58 Paging subsystems in the era of bigass memory http://www.garlic.com/~lynn/2017d.html#61 Paging subsystems

Re: Paging subsystems in the era of bigass memory

On Wed, 12 Apr 2017 12:44:32 -0400, Tony Harminc wrote: >On 12 April 2017 at 10:16, Tom Marchant < >000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: >[DB2] > >> It still makes no sense to me. It certainly can't read the record into the >> same page, because that would require that the page

Re: Paging subsystems in the era of bigass memory

On 12 April 2017 at 10:16, Tom Marchant < 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: [DB2] > So, if it thinks it would be faster to read the record from DASD than for > MVS to page in the buffer page(s) containing the record, it will read the > record into different pages that have

Re: Paging subsystems in the era of bigass memory

On 04/12/2017 10:16 AM, Paul Gilmartin wrote: > On Wed, 12 Apr 2017 09:50:44 -0500, Joel C. Ewing wrote: >> GETMAIN returns a success indication based purely on whether virtual >> storage is available to the address space within the REGION size >> constrains. >> > Does it not check for available

Re: Paging subsystems in the era of bigass memory

ibmsysp...@ibm-sys-prog.com (Avram Friedman) writes: > While they do not grow in in perfect lock step The presence of Big ass > memory comes with big ass dasd volumes (these are the technical terms > of course) Do you know 3350's and 2314s were once used as paging > devices? For that matter do

Re: Paging subsystems in the era of bigass memory

On Wed, 12 Apr 2017 09:50:44 -0500, Joel C. Ewing wrote: > >GETMAIN returns a success indication based purely on whether virtual >storage is available to the address space within the REGION size >constrains. > Does it not check for available paging space? Does this imply that your job and my job

Re: Paging subsystems in the era of bigass memory

On 04/11/2017 05:41 PM, Paul Gilmartin wrote: > On Tue, 11 Apr 2017 16:45:10 -0500, Greg Dyck wrote: > >> On 4/11/2017 3:26 PM, Paul Gilmartin wrote: >>> My understanding, ancient, probably outdated, and certainly naive is that >>> there is little communication between GETMAIN/FREEMAIN and the

Re: Paging subsystems in the era of bigass memory

>> Subject: Re: Paging subsystems in the era of bigass memory >> >> On Wed, 12 Apr 2017 06:28:05 +, Vernooij, Kees wrote: >> >> >From here, there the story still goes on IIRC: if DB2 again needs >> >the data, it would be paged in in any normal task. Howeve

Re: Paging subsystems in the era of bigass memory

to 10 mod-54's as my final solution >for this LPAR (roughly 4x the real memory). I wondered what the rest of >you are doing with your paging subsystems in the era of bigass memory sizes. > >Regards, >Tom Conley > >-- > > > >

Re: Paging subsystems in the era of bigass memory

> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Tom Marchant > Sent: 12 April, 2017 15:03 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Paging subsystems in the era of bigass memory > > On Wed, 12

Re: Paging subsystems in the era of bigass memory

On Wed, 12 Apr 2017 06:28:05 +, Vernooij, Kees wrote: >From here, there the story still goes on IIRC: if DB2 again needs >the data, it would be paged in in any normal task. However, DB2 >is more intelligent: it keeps track of how long it takes to page-in >the page or read it again from

Re: Paging subsystems in the era of bigass memory

On Wed, 12 Apr 2017 06:18:29 +, Vernooij, Kees wrote: >The advantage of not freeing the aux slot was that a page could >be paged out without I/O if it had not been changed. Somewhat >the opposite op page reclaim. Freeing it after it has been changed >is of course a 100% useful reclaim of

Re: Paging subsystems in the era of bigass memory

> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Blaicher, Christopher Y. > Sent: 11 April, 2017 21:25 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Paging subsystems in the era of bigass memory > > It

Re: Paging subsystems in the era of bigass memory

> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Greg Dyck > Sent: 11 April, 2017 23:39 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Paging subsystems in the era of bigass memory > > On 4/11/2017 1:46 PM

Re: Paging subsystems in the era of bigass memory

> > But like any design tradeoff, there are drawbacks as well, and with > real > storage > less expensive and more plentiful, you can have a lot more virtual pages > consuming both an aux slot and a real frame. There has been some > thought given to changing things so that we always free the

Re: Paging subsystems in the era of bigass memory

ml#58 Paging subsystems in the era of bigass memory http://www.garlic.com/~lynn/2017d.html#61 Paging subsystems in the era of bigass memory dynamically switching between "dup" and "no-dup" ... "no-dup" was when total processor memory was compareable in size t

Re: Paging subsystems in the era of bigass memory

> > If a virtual page is not 'getmain assigned' by VSM it will never be backed > > by a real frame by RSM and an 0C4-11 will occur. When all virtual storage > > on a page is freed VSM will return the allocated AUX slot and real frame, > > if either have been allocated, and reset the 'getmain

Re: Paging subsystems in the era of bigass memory

> What about the other side? Will GETMAIN return indication of success > only if the requested page slots can be committed? There is no consideration of aux slot availability when virtual storage is being allocated. There used to be some capability to reserve aux slots when an address space

Re: Paging subsystems in the era of bigass memory

>Many moons ago code was implemented in ASM and RSM to slowly reclaim ASM >page slots for virtual pages that were changed in real storage. I have >vague memories of this functionality later being disabled for some >technical concern, but can't remember what it was. Slot Scavenger was

Re: Paging subsystems in the era of bigass memory

t...@harminc.net (Tony Harminc) writes: > Not quite sure what you're saying. The old, constrained-memory > technique was usually to issue a variable (Vx) GETMAIN, specifying the > minimum required size as the low bound, and the maximum useful as the > high. Then the system returns the actual

Re: Paging subsystems in the era of bigass memory

On Tue, 11 Apr 2017 16:45:10 -0500, Greg Dyck wrote: >On 4/11/2017 3:26 PM, Paul Gilmartin wrote: >> My understanding, ancient, probably outdated, and certainly naive is that >> there is little communication between GETMAIN/FREEMAIN and the paging >> subsystem. If a program touches a page that

Re: Paging subsystems in the era of bigass memory

On 11 April 2017 at 17:45, Greg Dyck wrote: > If a virtual page is not 'getmain assigned' by VSM it will never be backed > by a real frame by RSM and an 0C4-11 will occur. When all virtual storage > on a page is freed VSM will return the allocated AUX slot and real frame, >

Re: Paging subsystems in the era of bigass memory

On 4/11/2017 3:26 PM, Paul Gilmartin wrote: My understanding, ancient, probably outdated, and certainly naive is that there is little communication between GETMAIN/FREEMAIN and the paging subsystem. If a program touches a page that was never GETMAINed no error occurs; simply a page slot is

Re: Paging subsystems in the era of bigass memory

On 4/11/2017 1:46 PM, Jesse 1 Robinson wrote: 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.

Re: Paging subsystems in the era of bigass memory

On 4/11/2017 2:24 PM, Blaicher, Christopher Y. wrote: It has been a while since I worked on DB2, but it is sounding like your buffer pools are too big. With large memory systems everyone should have all of the production (and, ideally, test systems too) buffer pools define with PGFIX(YES)

Re: Paging subsystems in the era of bigass memory

On 11 April 2017 at 16:26, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > If a program touches a page that was never GETMAINed no error > occurs; simply a page slot is allocated up to the limit of the REGION > parameter. Conversely, on FREEMAIN the page slots are not

Re: Paging subsystems in the era of bigass memory

On 2017-04-11, at 12:47, Jesse 1 Robinson wrote: > > 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 >

Re: Paging subsystems in the era of bigass memory

Carmen From: "Christopher Y. Blaicher" <cblaic...@syncsort.com> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, April 11, 2017 2:24:54 PM Subject: Re: Paging subsystems in the era of bigass memory It has been a while since I worked on DB2, but it is sounding like your buffe

Re: Paging subsystems in the era of bigass memory

@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Tuesday, April 11, 2017 2:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Paging subsystems in the era of bigass memory The problem we face is 'paging creep'. Right after IPL, systems show 0% ASM usage for some period of time. Then usage starts

Re: Paging subsystems in the era of bigass memory

On 4/11/2017 8:54 AM, Doug Henry wrote: Hi Tom, We have a pair of SCM cards (so in case one fails). Each card has 1.4 Terabytes of memory. For an lpar that has 524GB online and the SCM online is 384G. As for the cost I don't really know. ISTR a pair of flash cards is somewhere around

Re: Paging subsystems in the era of bigass memory

2017 1:52:06 PM Subject: Re: Paging subsystems in the era of bigass memory On 4/11/2017 2:46 PM, Jesse 1 Robinson wrote: > 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 > warn

Re: EXTERNAL: Re: Paging subsystems in the era of bigass memory

oing fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Conley Sent: Tuesday, April 11, 2017 11:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL: Re: Paging subsystems in the era of bigass memory On 4/11/2017 2:46 PM, J

Re: Paging subsystems in the era of bigass memory

On 4/11/2017 2:46 PM, Jesse 1 Robinson wrote: 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

Re: Paging subsystems in the era of bigass memory

robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Conley Sent: Tuesday, April 11, 2017 11:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Paging subsystems in the era of bigass memory On 4/11/2017 1:16 PM

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

Re: Paging subsystems in the era of bigass memory

. Bart -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pinnacle Sent: Tuesday, April 11, 2017 10:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Paging subsystems in the era of bigass memory Gone are the halcyon days when we could run an LPAR

Re: Paging subsystems in the era of bigass memory

Don't forget about PAGTOTL in SYS1.PARMLIB(IEASYS00). Default is 40. Extra slots reserve ESQA, so don't be overly generous. HTH, I had the total number of pages allocated and available in the current paging subsystem, so I calculated the available pages with 22 more mod-9's and then divided

Re: Paging subsystems in the era of bigass memory

On Tue, 11 Apr 2017 12:36:10 -0400, Tom Conley wrote: >I had the total number of pages allocated and available in the current >paging subsystem, so I calculated the available pages with 22 more >mod-9's and then divided the allocated pages into the new total pages

Re: Paging subsystems in the era of bigass memory

On 4/11/2017 12:03 PM, Lizette Koehler wrote: Tom How did you determine you needed 22 more MOD9s. Is there a formula you used? Lizette Hi Lizette, I had the total number of pages allocated and available in the current paging subsystem, so I calculated the available pages with 22 more

Re: Paging subsystems in the era of bigass memory

nal solution >for this LPAR (roughly 4x the real memory). I wondered what the rest of >you are doing with your paging subsystems in the era of bigass memory sizes. > >Regards, >Tom Conley > The 3 largest LPARs in terms of memory in one of the sysplexes I support are: 286G, running dev

Re: Paging subsystems in the era of bigass memory

LISTSERV.UA.EDU > Subject: Paging subsystems in the era of bigass memory > > Gone are the halcyon days when we could run an LPAR with three mod-3's as the > local paging subsystem. With today's large memory sizes, I'm faced with > having to completely rethink my paging subsystems. I'v

Re: Paging subsystems in the era of bigass memory

t;> you are doing with your paging subsystems in the era of bigass memory sizes. >>> >>> Regards, >>> Tom Conley >> Hi Tom, >> We use Storage Class Memory to solve the problem. >> >> Doug Henry >> USBANK >> > >Hey Doug, > >Oh,

Re: Paging subsystems in the era of bigass memory

On 4/11/2017 11:20 AM, Doug Henry wrote: On Tue, 11 Apr 2017 10:46:40 -0400, Pinnacle <pinnc...@rochester.rr.com> wrote: I wondered what the rest of you are doing with your paging subsystems in the era of bigass memory sizes. Regards, Tom Conley Hi Tom, We use Storage Class Memory to

Re: Paging subsystems in the era of bigass memory

On Tue, 11 Apr 2017 10:46:40 -0400, Pinnacle <pinnc...@rochester.rr.com> wrote: I wondered what the rest of >you are doing with your paging subsystems in the era of bigass memory sizes. > >Regards, >Tom Conley Hi Tom, We use Storage Class Memory to solve the problem.

Paging subsystems in the era of bigass memory

paging subsystems in the era of bigass memory sizes. Regards, Tom Conley -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN