With this in mind, has anybody experienced problems starting the
server when setting the BUFPOOL parameter to a very large number
(e.g. 384MB on a 512MB system)?

On our old server (SP wide node) we were able to get the server
up and running, but the amount of paging that occurred was
intolerable, so we dropped to 256MB. We've since moved to an F50
and have also ascertained some vmm parameters that may prevent
the thrashing/paging we experienced before. We have been unable
to test these new settings, however, because the server will not
start with the BUFPOOL set to 384MB. It simply begins its startup
process and ends with a "Server Killed" message.

"It's a dog eat dog world,                Thomas A. La Porte
 and I'm wearing milkbone underwear."     DreamWorks SKG
              - Norm Peterson             <tlaporte AT anim.dreamworks DOT com>

On Thu, 5 Mar 1998, Dan Giles wrote:

>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
>