Re: 6.5.4 NSF_BUFFER_POOL_SIZE_MB (was: two questions)

Chris, Eric, Sean,

First of all: Thank you very much for your responses and information.
I will try and be as complete as possible in my answers:

> Are you running all the DPARs out of the default memory pool or did  you
> setup a pool(s) for Domino?

Yes, since the iSeries are DSD's, we simply use the *BASE pool.

> I have 3 dpars (mail, app, im) and I have right at 4400 MB memory. You 
do 
> have the buffer pool set at the recommended (Total / # of DPARS * 3/8). 
> But that could be causing some issues - what happens if you leave it at 
> the default of 300?

We have 4 DPARS per iSeries. Total 12 iNotes mailservers, 2 hubservers, 2 
smtp. 
Same issue if we leave the buffer at 300 MB. No significant difference, 
though I would expect the issue to happen sooner.

> My fist pass would be to remove the buffer pool setting entirely.
> I do not think 3,500 MB is enough for 4 domino servers under load 
serving 
> Web pages pages or DWA. How many users per server etc?

1800 - 2000, 100 - 500 concurrent.

> How many processors do you have?

4 (iSeries 820), average 30 - 40% CVE load

> The way we estimate our buffer pool:
> Issue a SH STAT DATABASE
> Find the DATABASE.DBCACHE.HIGHWATERMARK entry and record it:  (eg. 1200)
> Divide this number by 3 since 3 entries for every 1MB of storage are 
cached
> (eg. 1200/3 = 400)

Ooops: our mailserver highwatermarks are at 1500-1800. 

> Honestly, if you have support agreement with
> Lotus, I would call and have a memory performance eval performed and 
they
> will make recommendations.

We did. And we did some tuning based on their suggestions. 
(for instance changed the max active threads in base pool from 600 fixed 
to 1200 calc)
They didn't say that our memory is insufficient, which it appears to be 
reviewing your suggestions.

I guess using the PercentAvailSysResources instead of the bufferpoolsize 
is the best way to go now.
Or order a few Gigs of memory. ;-)
At the moment the servers are running fine. Fingers crossed.
Thanks again,

Arjen