Hi,

Here Helen advice "more doesn't mean better with page cache". What about
with users that do need to handle a lot of data as query results (i.e.
monthly bill generation of a service company with millions of records to
select and insert in the same process) and most of the other users that just
perform small transactions?
Isn't there another solution than to replicate and use different servers?

Ramiro

2009/12/11 emb_blaster <EMB_Blaster@...>

>
>
> > Or is there a link to this information available (in case that was
> answered
> > before already) ?
> >
> > Many thanks,
> > N.
>
> Hi Nico
>
> you could do a search on messages containing the words "Classic Superserver
> page size buffers" and found many interestings posts about this. ex.: see
> this message from Helen in feb 2009.
>
> >>>
> Page Size 8192 * Buffers 20480
>
> Means a 160MB cache buffer - fatally large for Classic which allocates the
> same
> amount of cache for *each* connection. Probably also exorbitant for SS,
> unless
> you're running a 64-bit server on a 64-bit OS -- it's 10* the default (16
> MB for
> your page size). Try 128 pages for Classic and maybe 4092 pages for
> SS...you
> can move a bit forward or backward from there as your testing progresses to
> get
> a handle on optimal settings for your type of usage.
>
> Actually, "more" doesn't mean "better" with page cache if you don't have
> oodles
> of otherwise unused RAM available. As soon as the cache has to swap to
> disk,
> you've lost its benefit. On a 32-bit OS you have only a *total* of 2 GB
> available for an entire process which, for SS, means all of your concurrent
> connections.
>
> Tip: if you keep the buffers size at 0 in the database header, you can set
> the
> DefaultDbCachePages parameter in the firebird.conf of each respective
> server, to
> avoid having to change the database header each time you switch server
> models.
>
> ./heLen
> <<<< was trunc
>
>
>

--
Ramiro Barreca
rbarreca@...


[Non-text portions of this message have been removed]