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 [email protected] with the message: INFO IBM-MAIN
