> Reduce de Cache Size to something between 8000-10000. There is a known
> limitation on the FB 1.X dirty page algorithm that tends to slow down
> with Cache Size greater than 10k. FB 2.0 can handle bigger caches
>

Thanks for all the input.

I reduced the cache size to 10k for one database and 4k for the other.
The latter is really small and hold only one table. Now I simply hope
that the database server will not ever try to address more than 2G of
memory. It would be nice to have some sort of guarantee. The overall
default cache size now is 114,688,000 bytes and I have almost 2G of
space to expand, but this may not be enough. Before I had more than a
1 G of expansion space and it filled up pretty quickly.

Perhaps the handling of this error needs to be different, because
whenever this error occurred, one of the databases on the server
simply became unaccessible: whenever you try to connect to/access that
database you would get "gds consistency error...". We were lucky that
we were at work when this happened and the database were down for no
more than 15 minutes. I think that in this case even a forced
restart/shutdown would be better way to handle this. The guardian
should always start up the server if it was shutdown.

Anyways, this whole issue seems weird to me. I always thought that the
bigger the cache, the faster the database, that's why we got ourselves
a 4G database server, but it turned out otherwise.