>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