What release of z/OS are you running Lizette? I know the defaults for zfs memory usage went up in 1.13. Pretty sure these are the defaults too:
meta_cache_size=100M metaback_cache_size=415M trace_table_size=200M user_cache_size=515M xcf_trace_table_size=8M _________________________________________________________________ Dave Jousma Assistant Vice President, Mainframe Engineering [email protected] 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Lizette Koehler Sent: Monday, November 24, 2014 10:46 AM To: [email protected] Subject: Re: Page Data Set Sizes and Volume Types Okay, I get that. However, I seem to be using a high amount of Page Datasets and the only thing I can see is zFS. In fact I am right now trying to size the zFS environment so it uses a smaller foot print. There are no frequent SVC Dumps on this system. I will ask for zFLASH to be looked at. Thanks Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Cheryl Walker > Sent: Monday, November 24, 2014 8:07 AM > To: [email protected] > Subject: Re: Page Data Set Sizes and Volume Types > > Hi Lizette, > > Did you take a look at that Techdoc? It shows you how to calculate the number of > slots. > > Regarding using larger rather than smaller data sets, it depends on > what happens to > your online performance during an SVC dump. In most installations, the only paging > occurs during an SVC dump. If you can monitor performance during that > time (e.g. > online response time) and amount of paging, you might be able to > determine whether a change in performance will affect you. > > Best regards, > Cheryl > > ====================== > Cheryl Watson > Watson & Walker, Inc. > www.watsonwalker.com > cell & text: 941-266-6609 > ====================== > > On Nov 24, 2014, at 9:35 AM, Lizette Koehler <[email protected]> wrote: > > Thanks to all with help on this topic. > > Cheryl. Thanks very much. I was hoping to find a formula to > determine the number > of slots, but I think MXG can help with that. > > I also was trying to determine if I can swap out 20 Mod3s for 2 Mod27s > and not > have to create little datasets on the Mod54. > > I have a sandbox and I will be attempting to arrange some validations > of my > assumptions. > > Lizette > > > > -----Original Message----- > > From: IBM Mainframe Discussion List > > [mailto:[email protected]] On Behalf Of Cheryl Walker > > Sent: Monday, November 24, 2014 7:30 AM > > To: [email protected] > > Subject: Re: Page Data Set Sizes and Volume Types > > > > Hi Lizette, > > > > Here's an item from our latest Tuning Letter (2014 No. 3). This > > might help > a little. > > > > Page Data Set Usage > > > > Tom Kelman of Xerox Business Services, LLC asked: "I have heard that > > the process where the paging subsystem attempts to block pages > > together to > send them > > to the paging data sets went away around z/OS 1.7 or 1.8. Is that > > true, > and if so is it > > still necessary to keep the percent of local page space used down to 30%?" > > > > To answer the first part of his question, z/OS 2.1 still supports > > block > paging. The > > 30% number is to make the contiguous slot algorithm most efficient. > Contiguous > > slots are used even if block paging is not in play. > > > > To answer the second part of his question, yes, the recommendation > > is > still 30%, > > although it could be more or less. It's relatively easy to calculate > > the > best value for > > your installation. Here is an excellent paper on how to do the > calculation: Techdoc > > TD104728 (z/OS Availability: Managing SVC Dumps to Mitigate > > Exhausting the Paging Subsystem). > > > > It all has to do with SVC dumps. SRM will identify a storage > > shortage if > you use > > more than 70% of the page data sets. While taking an SVC dump, you > > don't > want to > > take more than 70% of the page slots. Therefore, IBM recommends that > > you > keep > > the total auxiliary dump space and paging space to less than 60% of > > the > slots. It > > really depends on how much storage you have, how big your SVC dumps > > are, > and > > how many concurrent dumps you are likely to experience. > > > > We asked Kathy Walsh, Distinguished Engineer at IBM's Washington > > Systems Center, whether the availability of Storage Class Memory > > (SCM) has any > effect on > > this recommendation. Her reply: > > > > If you have SCM on the LPAR then assuming its service time is faster > > it > will get > > most of the pages, except for VIO which is not written to SCM. So as > > far > as I am > > concerned the recommendation has not changed. For locals we still > > don't > want them > > more than 30% used. Of course with SCM it will be hard to get to 30% > unless there > > is a lot of VIO activity. With SCM there has been no change in the > > Aux > DASD IO > > support hence nothing has changed which would merit a change in > > recommendation. > > > > And while we're mentioning SCM, we want to remind you of our article > > in > Tuning > > Letter 2013 No 3 (IEASYSxx Update): > > > > [The IEASYSxx keyword] PAGESCM indicates whether and how much > > storage- class memory (SCM - also known as FlashExpress or zFlash) > > to allow for > paging > > data sets. We described zFlash, which is a priced (about $125K per > > 1.4 TB > in the > > U.S.) hardware feature on a zEC12, in our Tuning Letter 2013 No. 1, > > pages > 4-7. Our > > recommendation for zFlash was: > > > > RECOMMENDATION: If SVC dumps are hurting performance, if the start > > of day brings serious performance problems, or if you want to > > provide performance enhancements in Java, DB2, or IMS, you should > > consider Flash Express for > your > > zEC12. It has great potential, and I haven't heard of any downsides. > > > > Best regards, > > Cheryl > > > > ====================== > > Cheryl Watson > > Watson & Walker, Inc. > > www.watsonwalker.com > > cell & text: 941-266-6609 > > ====================== > > > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
