X Memory needs X disk for paging backup. Then a System dump needs to copy Memory + Pages, so 3X disk for X Memory. Also leads to the guidance that over 30% percent usage of slots you need to consider increasing disk paging.
On Tue, Nov 5, 2019 at 10:44 AM Allan Staller <[email protected]> wrote: > > 10TB real 30TB Paging. > > Implies 3:1 virtual to real. > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf Of > Mike Schwab > Sent: Tuesday, November 5, 2019 10:39 AM > To: [email protected] > Subject: Re: How display level of paging? > > 10TB real 30TB Paging. > > On Tue, Nov 5, 2019 at 10:35 AM Allan Staller <[email protected]> wrote: > > > > I never based my estimates on the amount of real. Only on the Virtual. > > > > Using our same 10TB system with a 2:1 virtual to real would result in 20 TB > > page slots and a 60TB paging subsystem. > > > > > > > > -----Original Message----- > > From: IBM Mainframe Discussion List <[email protected]> On > > Behalf Of Tom Marchant > > Sent: Tuesday, November 5, 2019 8:56 AM > > To: [email protected] > > Subject: Re: How display level of paging? > > > > On Mon, 4 Nov 2019 17:46:12 -0500, Tom Conley wrote: > > > > >I posed this same question about 2 years ago. Then I was dealing > > >with an LPAR with 131GB, so I created a 400GB paging subsystem to > > >handle the system. Others suggested SCM, but that was not in the > > >budget. If the 10TB is truly fully utilized, then a 30TB paging subsystem > > >makes sense. > > >Unless I hear differently from IBM, paging rules still apply, even > > >for 10TB systems. > > > > Looking at one of our bigger LPARs here, we have > > > > 66 GB of storage > > 8 local page data sets that fill 3390-9 volumes (total 68 GB) > > 264 GB SCM paging devices > > > > So we are well within what you think is needed. I am not the sysprog here, > > but if I was I would not be opposed to reducing it because: > > > > The local page data sets are all 0% full The the SCM is using 64 M of > > the 264 GB > > > > Admittedly, we are a small shop. We are also a development shop and take a > > fair number of SVC dumps. > > > > Those old rules were from the days when memory was expensive and paging was > > common. Back in the 80's it was not uncommon to page at rates of 50 to 100 > > pages per second on a machine with 32 to 64 MB of main storage, and have 5 > > GB or more of page space utilized. Today, paging, and page space > > utilization, is normally much less. > > > > What I would suggest that you need for page space today is more like the > > sum of: > > > > Maximum virtual storage in use minus real storage, multiplied by 3 and > > Enough to support the capture of the biggest possible SVC dump, multiplied > > by 3. > > > > I don't remember a time that the recommendation was to size paging > > subsystems based upon the amount of real storage on the processor. > > Indeed, 30 years ago that would have been wholly inadequate. > > > > I don't buy the suggestion that an LPAR with 10 TB of storage should have > > 30 to 90 TB of paging space. > > > > I'll close with this observation. A z15 processor can have a maximum > > of > > 40 TB of customer storage. The maximum amount of SCM is 6 TB. You want to > > configure your paging subsystem so that paging to DASD is rare, and almost > > all paging is to SCM, because SCM is so much faster. > > > > -- > > Tom Marchant > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to [email protected] with the message: INFO IBM-MAIN > > ::DISCLAIMER:: > > ________________________________ > > The contents of this e-mail and any attachment(s) are confidential and > > intended for the named recipient(s) only. E-mail transmission is not > > guaranteed to be secure or error-free as information could be intercepted, > > corrupted, lost, destroyed, arrive late or incomplete, or may contain > > viruses in transmission. The e mail and its contents (with or without > > referred errors) shall therefore not attach any liability on the originator > > or HCL or its affiliates. Views or opinions, if any, presented in this > > email are solely those of the author and may not necessarily reflect the > > views or opinions of HCL or its affiliates. Any form of reproduction, > > dissemination, copying, disclosure, modification, distribution and / or > > publication of this message without the prior written consent of authorized > > representative of HCL is strictly prohibited. If you have received this > > email in error please delete it and notify the sender immediately. Before > > opening any email and/or attachments, please check them for viruses and > > other defects. > > ________________________________ > > > > ---------------------------------------------------------------------- > > 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 -- 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
