Thomas Løcke wrote:

> ...
>> ...
> The current Firebird DB (was running an old version of Interbase up
> until a few weeks ago) is completey out of my hand. I have NO idea
> what's going on inside the application itself, and the people who've
> build it are very reluctant to release the information needed to conduct
> the tests you mention.
>
> What I do know is that Firebird is currently sucking up 50-60% of the
> servers resources. If we're unlucky, several hits happen at the exact
> same time, and then we max out pretty fast. This is not in itself a
> problem. The problem is that when this happens, other parts of the
> software start to act weird. We have for example a system in place for
> playing .vox files, and this system starts to stutter a lot when the CPU
> is running at 100%. By moving the DB away from the application server, I
> can instantly eliminate this problem.
>
> So my real issue here isn't as such the performance of the Firebird
> database, as much as it is how it affects the remaining system.
>

The db server process should largely be limited
by the performance of the disk system (not CPU
bound). Your description of performance problems
hints at a "potential for improvement".
1. Transaction handling is very important.
2. Check "plans" for your queries. See if you
need to create some indexes (and whether you
should drop some indexes). Also, queries might
need some tuning if the Firebird optimizer does
not choose the best plan. Start by identifying some of the slow queries.


--
Aage J.