Subject Re: [firebird-support] Recommended firebird.conf settings for a classic server on 2003
Author Helen Borrie
At 05:45 PM 3/01/2008, you wrote:
>Hi Guys,
>I'm trying to troubleshoot a poor performance issue with a firebird DB
>based app for a client. They are running a 15 GB database, ~40 users, on
>a windows 2003 server (single drive, raid5),

Raid5 on a single drive? Howzat? Are there external drives not mentioned? If you *really* have only one drive, disable the Raid5 driver, in case it is hobbling the disk speed in some way.

>dual Xeon and 2 GB RAM.
>Currently it is in classic server mode, and I believe a default config
>file apart from the CPU affinity.

"apart from the CPU affinity" - can you explain what you did? Reason for question: CPU affinity isn't an issue for Classic. *If* a Classic process can affine to a single CPU (and I'm not sure that it can), then changing the default would make sense...


>Now I'm wondering if anyone can give me or point me in the right
>direction for a set of changes I should be making to the firebird.conf
>file as a baseline. I've had a hunt around and believe theres a couple
>of settings for max memory and temp dirs but was hoping for a complete
>list as a starting point.

The most important one to look at for Classic is the default page cache size. Because (unlike Superserver) each Classic connection has a whole fb_inet_server process to itself, a database whose cache setting was previously configured for SS will be a dog on Classic. 2 GB isn't a whole lot of RAM for 40 processes. In case you don't know how to find out the cache size, assume the server's hostname is tlcit and the database alias is tenderlovin --

(in firebird's \bin\ directory):

gstat -h tlcit:tenderlovin

Read the Page size and Page buffers figures and multiply them together and divide by 1024. Something around 300K would be the maximum, but probably less if the application is doing a lot of sorts (ordered queries, groupings...).

As for the whole gamut of things to tweak and twig...not usually a great idea to fiddle about with all of them en masse. Every database is different - you might find you need to configure more sort memory, if you find a lot of sorts going into your temp sort space on disk...if so, then with 2 GB RAM you'd need to lower your sights re page cache.

It's a bit of a disadvantage running 32-bit Classic for 40 users with only one hard drive and limited RAM. You lose the benefit of the per-process extra resources available (up to 2 GB per process). Ideally you'd want to ramp up the RAM because you actually *can* use it; and/or have a fast ancillary drive for sorts that go to disk and configure plenty of space on it.

./heLen