Subject Re: [ib-support] Is the cache guaranteeed to reside in physical memory?
Author Helen Borrie
At 12:42 PM 30-09-02 +0200, you wrote:
>I wrote:
>
> > I have to work out a -buffers setting that could be a reasonable default
> > for both stand-alone installations and multiuser with a server
> > (presumably more RAM that the stand-alone thing).
> > Given that I have 4KB pages, I think 5000 pages is a suitable value for
> > our database, but was wondering: will IB try to allocate upto 20MB (4 x
> > 5000) even if they're gonna come from the pagefile, or will it stop when
> > there's not enough physical memory available?
> > I don't want to keep the 75 page server default, but I obviously don't
> > want to defeat the cache.
> > Does aanyone know for sure? I'm using IB5.6.

Nando,
You will defeat the cache if you allocate a default number of pages that
exceeds the amount of RAM you have to spare. Assuming the server isn't
doing a whole pack of other stuff or running a RAM-intensive admin GUI, the
trick seems to be to calculate the maximum amount of RAM that will be used
by the maximum number of users likely to be connected doing the maximum
amount of work likely to be performed simultaneously. Subtract that value
from the physical RAM available, translate that into database pages and use
that for your default cache.

Yes, the cache will spill over into into pag memory if physical memory is
inadequate. Since the purpose of the cache is to avoid unnecessary disk
i/o it doesn't make a whole lot of sense to set up a cache that will
"overflow" constantly to disk.

>hasn't anyone got a clue?

Like so many configuration things, it's likely to be very specific to your
users' operating environment.

>Or is it a false problem?

No, just not an easy problem to provide a rule-based solution for. In my
experience, it's a thing best handled as part of your soak-testing, where
you are presumably well set up to throw a lot of different variables into
the mix.

It's doubtful you would arrive at a setting which will work equally well
for stand-alone and multi-user deployments.

heLen