Am 27.08.2010 14:05, schrieb Doug Chamberlin:

> You don't say what the actual problem is that you are facing. Is the
> application too slow? Was it faster before? If so, what changed?
>
> What makes you think it is Firebird that is the cause?

The app gets slower over time, maybe because it is written suboptimal,
maybe because overall data grows and grows ...

We just wonder why the database-server swaps out so much and if we might
change this behavior by configuring firebird.

That server doesn't do anything else ...

>> The firebird.conf was completely *default* as I looked at it.
>
> This is not at all unusual in the Firebird world. Many sites require
> no tuning.

ok ...

>> Maybe the app itself is slow or buggy or something, sure, but what
>> can I do to tune firebird itself?
>>
>> I already increased DefaultDbCachePages from 75 to now 300 ...
>
> This change may or may not improve things. But so say there is unused
> RAM in the VM so maybe this value could be increased another 100.
> Try it.

ok, we will try that.

> It seems you are running Firebird classic.

Yes, I said so in an earlier mail in this thread.

The database page cache

> should be kept on the smaller side since it occurs for each
> connection process, so DON'T think about increasing it to 2048 or
> so.

Yep, I already understood that it applies to each single process.

> Are you sure the VM is fully allocated the 8GB in actual RAM by the
> host server?

Yep, we are. The host has 64 GB of RAM and is using about the half of
its RAM now, so the 8 gigs of the db-server should be fully in RAM as well.

>> afai understand we have a pagesize of 16 MB
>> (?).
>
> No, that might be 16KB but not 16MB. Page size is like sector/cluster
> size on a file system - the database is allocated and accessed via
> pages of this size.

Ah, ok, my mistake.

Thanks for your feedback, Stefan