Hi Scott,
How are you doing? From my experience on the ADSM help desk, I've found that 98%
is definately the magic number that you want to strive for. I have personally
seen 3 or 4 other sites with the problem, having the same results.
So, the moral: get that db cache hit ration over 98%!
From: Scott McCambly <mccambly AT NETCOM DOT CA> on 03/02/98 06:55 PM GMT
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc: (bcc: ADSM)
Subject: Re: EXPIRE INVENTORY processing in V3
Hi again,
Thanks for the response (thanks to Michael Vogt for the direct reply too).
Bill wrote:
>the version 2 message doesn't report 'object examined. The
>cache hit ratio is 98.51, just a little better than yours
>but not enough to account for the huge performance
>difference.
Well, I have increased my BUFPOOLSIZE by 8x to 132MB, and although my cache
hit ratio only went up from approx 96% to approx 98%, my expiration
processing is now examining and deleting as many files IN ONE HOUR as it
did in TWO DAYS before!!!!
I wanted to make sure everyone on the list sees this. The 98% value seems
to be a critical indicator of database efficiency. I can't wait to see how
much faster everything ELSE runs now. ;-)
By the way, the larger memory requirement seems to have gotten really
noticable since we upgraded to V3.
Thanks again,
At 12:05 PM 02/03/98 -0500, you wrote:
>In <3.0.3.32.19980302111230.0089fb10 AT popd.netcom DOT ca>, on
>03/02/98
> at 11:12 AM, Scott McCambly <mccambly AT NETCOM DOT CA> said:
>
>>Hello everyone,
>
>>There has been discussion about changes to the Expiration
>>Processing in later versions of V2 and V3 releases of the
>>server. I was hoping someone from Development/Support
>>could give us an overview of exactly how Expiration works.
>
>>For example, our current problem is that we have let
>>expiration run for up to 5 days and it has never (recently)
>>completed. Yesterday I stopped it at the following point:
>>287,312 examined and 256,474 deleted. I immediately
>>restarted it and the examined to deleted ratio as it
>>progressed was about the same! Today after approximately 16
>>hours the stats are: 97,778 examined and 97,075 deleted.
>
>>Did it start over from the beginning or does it pick up
>>from where it left off?
>
>>Is there any way for me to query the total number of
>>objects in my database so I can get an idea of how much is
>>left to be examined?
>
>>Is there any reason I should let it fully complete, or can
>>I start and cancel expiration as required by my daily
>>scheduled activities?
>
>>Finally, do these stats seem low or normal? We have a 20GB
>>database running on an RS/6000 J40 (4 CPU) with AIX 4.2.1
>>and ADSM V3.1 (+latest fix), and by the way I just noticed
>>our Cache Hit Pct is 96.45%
>
>>Thanks very much,
>
>>Scott.
>>Scott McCambly
>>AIX/NetView/ADSM Specialist - Unopsys Inc. Ottawa,
>>Ontario, Canada (613)238-5620
>
>This seems awfully slow. I run expire inventory once a
>week. My adsm is on mvs, the adsm version is 2.1.0.13. The
>db is 5.8 million pages (about 23 Gb). It ran in 5 hr, 23
>min and expired 237,323 backups. This is pretty much how it
>goes every week.
>the version 2 message doesn't report 'object examined. The
>cache hit ratio is 98.51, just a little better than yours
>but not enough to account for the huge performance
>difference.
>
>To count the number of object, do a 'query occupancy',
>capture the output and sum the number of files. I think you
>should exclude the files in copypools. I have 31,000,000
>files.
>
>We are comparing apples and oranges as far as the hardware
>is concerned, so I can't say if that alone would account for
>the difference. I have an s/390 9672-r41 (1 processor, 45
>mips) with escon channels to STK Iceberg dasd.
>--
>-----------------------------------------------------------
>Bill Colwell
>Draper Lab
>bcolwell AT draper DOT com
>-----------------------------------------------------------
>
>
Scott McCambly
AIX/NetView/ADSM Specialist - Unopsys Inc. Ottawa, Ontario, Canada
(613)238-5620
|
