Thank you for your comprehensive answer!

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
>
> >Ivan Maradzhiyski wrote:
> >>
> >> My internet daemon is inetd, not xinetd.
> >> I fixed the problem.
> >> I decreased the number of buffer of the database, which Firebird uses
> >> for caching.
>
> You moved from Superserver to Classic. SS is a single process that
spawns threads for connections.
>
> -- SS has one page cache, which is shared by all connections.
> -- For CS, each connection is a separate process. Each connection
gets its own page cache.
>
> Thus, your page cache setting for SS would have been far too high
for CS. If you had each CS process being allocated the same amount of
RAM for page cache that SS would allocated for *all* connections, it
would not take many CS connections to exhaust RAM.
>
> >> As far as I know, Linux caches the file system in RAM.
> >> Does this setting(number of buffers) take effect under Linux or *BSD?
>
> It's my understanding that Linux caches the *structure* of the file
system in RAM and maintains the image in a tree structure. This is a
background activity of the OS that has nothing to do with Firebird's
page cache. Firebird maintains its own internal mapping of the
physical locations of everything it controls. The OS has no knowledge
of it.
>
> Firebird's page cache is not a copy of the database file. It is a
block of RAM where the database engine caches database pages and index
structures as they are read.
>
> In CS, the default amount of RAM allocated to each connection for
page cache is calculated by (Number_of_pages * page_size). If your
database has a large page size then the size of the RAM allocation per
Classic process for a buffer of n pages will be proportionately larger
than that allocated for a smaller page size. You have to take all of
the factors into account when setting page buffers for Classic,
remembering also that each process consumes ~ 2 Mb just to exist.
>
> ./heLen
>