Olaf,

> Hello Anderson, Helen and Fabian,
>
> now I'm confused.
>
> First my gstat -h statistics:
>
> Flags: 0
> Checksum 12345
> Generation 230320
> Page Size 4096
> ODS version 11.0
> Oldest transaction 833
> Oldest active 961
> Oldest snapshot 840
> Next transaction 229603
> Bumped transaction 1
> Sequence number 0
> Next attached ID 711
> Implementation ID 16
> Shadow count 0
> Page buffers 0
> Next header page 0
> Database dialect 3
> Creation Date Jun 6, 2008 10:31:39
> Attributes
>
> Sweep interval: 20000

First of all, you have a transaction management problem, because during
5 days of operation, the gap between OIT/OAT and next transaction grow
and will probably grow further.

Second: You are using your database with FORCED WRITES = OFF, which is
bad from a corruption point of view, although FORCED WRITES = ON works
on Linux reliable since Firebird 2.1, according to the release notes.

> The server has 4 GB of RAM.
>
> Firebird.conf: #DefaultDbCachePages = 2048 - I don't have changed at the
> time
>
>
> I have read all your responses.
>
> It is right, that I change the firebird.conf - value #DefaultDbCachePages =
> 2048 to DefaultDbCachePages = 75 ? or better 128?

This will be a server-wide setting then, thus valid for each database on
the server, which has the database specific page buffers value set to 0.

> I have three suggestions and different values. Shall I change also the Page
> Size?

A bigger page size will most influence the used RAM for caching.

It might also affect your database when working with BLOBs or you might
get better performance if your index depth is > 3 ... But I don't now
any statistics so far, which give you some reliable measures on how a
bigger page size will improve your database. These days, I usually use 8192.

As Helen mentioned, choosing the right page size and page buffers value
in respect to RAM and caching, it really depends on your usage pattern.
Number of databases on the server. Number of connections. Other
applications on the server using RAM ...

For instance, for an analytical database I'm using with Classic, which
basically does on-the-fly aggregation which needs to read a lot of data
pages, I'm using a much bigger page buffers value as previously suggested.

Although, I will have some kind of materialized view mechanism with
pre-aggregated dimensions in place soon. Then, I probably will reduce
the page buffers value again.




--
Best Regards,
Thomas Steinmaurer
LogManager Series - Logging/Auditing Suites supporting
InterBase, Firebird, Advantage Database, MS SQL Server and
NexusDB V2
Upscene Productions
http://www.upscene.com