I had thought (from https://www.ibm.com/developerworks/community/blogs/MartinPacker/entry/lla_and_measuring_its_use?lang=en ) that the SMF records did not really tell us very much about the tuning. But it could have been that I didn't really understand them
So we used the healthcheck iteratively to watch the trimmed age of the exceptions, and arrived at 64Mb. At 4MB the trimmed age was 1 day, at 32MB 11 days, at 48MB 30 days. At 64MB all our sysplexes seem not to be trimming within 60 days any more. That was a while ago, and we are just starting to look at the IGGCAS class which has also been tripping the healthcheck exception (at 1 day). Best regards, David Tidy IS Technical Management/SAP-Mf Dow Benelux B.V. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP (ITOPT1) - KLM Sent: 25 November 2014 15:47 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VLF Caching I have 200MB and have a 99% hitratio on 20 LLA managed libraries, as reported by LLA statistics (LLA fetches from its VLF cache)/(LLA fetches from VLF + LLA fetches from disk). Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Thompson Sent: 25 November, 2014 15:29 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VLF Caching On 11/25/2014 07:29 AM, Peter Relson wrote: > There is no rule of thumb. It's very likely that 16M is way too small, > but we're not likely to change the default. > 128M is fairly common, I believe. > > It's not necessarily the case that a bigger size is better. The more > data that is cached, the more likely you are to be able to retrieve > from the cache (which is a good thing) but the longer it may take to > locate the data (which is not a good thing). > > In the distant past some found that sizes of 256M and above were > detrimental. But no one that I know of actually did any analysis to > try to figure out "why". The guess was that the performance decrease > correlated to the number of objects that then were cached. > > It has probably been well over 10 years since I last heard any > discussion of this; I have no idea if what was seen was typical or > "one-off", or if it still behaves that way. > > Peter Relson > z/OS Core Technology Design > <SNIPPAGE> Thank you. I can tell you that 16MB is TOO SMALL. And so far, in our shop, 32MB is too small. The diminishing returns problem is going to be interesting to find. I know that you want to cache hi-use modules. But, if the module is beyond a certain size, you may not want to cache it - DASD fetch may be better. So, if you have sufficient cache, you can get all of your stuff in there w/o hitting the "10% headroom issue". And if the speed of XMEM is hi enough (based on CPU avail)... But, if cache is being used by all large modules, you can get into a cache "thrash" situation (old APAR/PTF for where it would loop) -- Fastest way I know to get the situation (it can be done with a mix...). We have noticed that at 16MB, we BURN MSUs in VLF TRIM (sorry, forgot the module name). So another aspect of tuning is setting the time lower to get things to be trim-able sooner. But, that can have diminishing returns.... So it may need to be set higher (sigh). Enter the EXITs. Now you have to have someone in your shop that knows ALC and management can give clear guidance to rules so they can be effected... (sigh). How about IBM and CA play nice and get CA the right stuff so they can fix PMO and QuickFetch for PDSEs (I can't believe I'm writing this!!). Later, Steve Thompson ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
