Replies inline... (resending, dont think the last couple got through)

Helen Borrie wrote:

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

Yes sorry I meant a single raid5 drive as seen by the OS, 3 physical
drives (thanks Ivan). Actually partitioned into system and data.

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

I double checked the config file and it is actually running a vanilla
firebird.conf with nothing set. Currently it is sitting with around
90-100 fb_inet_server processes with between 9-38 MB mem each.
It is also currently on FB 1.5.2, I'm planning on updating that however
it is a third party app and I'm waiting on them to perform some updates
to the program so I don't change too much at once.

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

I'll see if I can pull that info out and find out what it is.

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

Server actually has 3GB RAM installed, it has a few other jobs but the
FB DB is its primary. It is currently sitting with 1.9 GB RAM free - I
figure firebird should be able to use more of this at the very least.

Would it possibly be better to configure this as an SS install?
The biggest issue I have here is that it is of course a third party app
so not something I know all about, however we are trying to support the
server so trying to get things working satisfactorily without knowing a
lot about firebird (but learning).

Thanks for the info heLen, I'll try and get that info and get back to
the list.
-- Richard