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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
