On 8/26/2010 5:25 PM, Stefan G. Weichinger wrote:

> I subscribed to this list only yesterday after googling and browsing
> docs and stuff ...
>
> Sorry for maybe faq-ing here, but I am somewhat under some pressure now ...

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?

[snip]

> They never had a customer that big so they never had to tune or
> even configure firebird, as it seems.
>
> 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.

> 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.

It seems you are running Firebird classic. 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.

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

> We have the impression that the available RAM isn't used fully and too
> much swapping happens, which is a perfect performance-killer, sure ...
>
> RAM-usage is around 3 GBs (out of 8 available) and way too much swapping
> is done.
>
> I ran gstat.exe and 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.