ADSM-L

Re: cache hit rate

2002-08-22 02:47:25
Subject: Re: cache hit rate
From: Christo Heuer <christoh AT ABSA.CO DOT ZA>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 22 Aug 2002 08:41:10 +0200
Hi Ken,

OK - maybe there is a bit of conflicting info here - Let's begin
by saying you must try and have the hit ratio above 99% for
optimum performance (As stated in the performance and Tuning manual).
If you look at selftunebufpoolsize - it will adjust the buffpool
when your cache hit ratio is below 98% - indicating the general
rule that 98% is the cut-off point for acceptable performance.
Above 97%(in my mind anyhow is 98% or higher in any case).
I think what it should state is that it should not be lower than
98%....
Anycase - I've got experience on both sides of this figure - 96-97%
hit ratio my server was performing like a dog - and you will only
see this in expiration processing and big SQL queries - some of
my queries that create reports was running for 5 hours - they now run
in about half an hour. When you get a techie phoning you and saying
he's been waiting for an hour already just to get the list of files
to pick from during a restore you will know what I'm talking about.

The cache hit is now sitting at 99.11 and the performance from
everything is excellent.

When your cache hit ratio goes lower than 98% it indicates that
you have a performance problem somewhere - it might be like in
our case where our mainframe was running 100% CPU most of the day
and night - increasing the buffpoolsize in this case meant nothing.
Once we solved the CPU utilisation issues (By moving workload off
this mainframe), our cache hit ratio went back up and performance
is excellent.

So there you have it:
96%-97% - bad performance
97%-98% - OK - but not good (Let's call it acceptable)
98%-99% - Good performance
99%-100% - Excellent performance

Hope this helps!

Regards
Christo
----------------------------------------------------------------------
No experience.  I fact I'm learning from your experience.  While you say

"from my training at IBM that a cache hit rate of 99% and above is
recommended"

I found the following statement in the web interface.

The server database performs best with a cache hit ratio above 97% in the
database bufferpool. To tune the bufferpool size, (a) reset the bufferpool
statistics, (b) execute server operations that use the database, and (c)
view the database details to see if the cache hit ratio is above 97%. If the
cache hit ration is NOT above this percentage, increase the size of the
BUFPOOLSIZE specification in the server options file.

Conflicting advice?  Perhaps your 97.7% is good and no problem exists.
Let's hear from others.  Please......


Ken
khoracek AT incsystem DOT com


>>> Sascha.Braeuning AT SPARKASSEN-INFORMATIK DOT DE 08/21/2002 12:46:04 AM >>>
Hi all,

first I've to thank all participants for the amount of answers I got on my
latest questions. Now I've got a new one which relates on the
bufferpoolsize and the cache hit rate on OS/390 TSM-Servers.

we use the following bufpoolsize:  32768
our chache hit rate:            97,7 %

I know from my training at IBM that a cache hit rate of 99 % and above is
recommended. Is it possible, that a lower cache hit rate can cause
performance-problems? What is your experience?


MfG
Sascha Bräuning


Sparkassen Informatik, Fellbach

OrgEinheit: 6322
Wilhelm-Pfitzer Str. 1
70736 Fellbach

Telefon:   (0711) 5722-2144
Telefax:   (0711) 5722-1630

Mailadr.:  sascha.braeuning AT sparkassen-informatik DOT de

______________________________________________
"The information contained in this communication is confidential and
may be legally privileged.  It is intended solely for the use of the
individual or entity to whom it is addressed and others authorised to
receive it.  If you are not the intended recipient you are hereby
notified that any disclosure, copying, distribution or taking action
in reliance of the contents of this information is strictly prohibited
and may be unlawful.  Absa is liable neither for the proper, complete
transmission of the information contained in this communication, nor
for any delay in itsreceipt, nor for the assurance that it is
virus-free."

<Prev in Thread] Current Thread [Next in Thread>