Thanks for your reply.

> But, something
> you didn't mention and I find very important are the hard drives.

Even with

> a small db (for now, but it will grow), since we have many

connections and

> for data security we choiced to have: 1 SATA drive for the system

(os, fb

> binary, and so), 1 SATA drive for temporary files and backup files

and 4 SAS

> drivers on a RAID 10 configuration for the DB file.
>

We use just 2 SAS drives mirrored in RAID.

What do you mean temporary files? Firebird temporary files? Would it
help to have them in a separate drive? Why not use a RAM drive?

> page buffers configured to something like 500 (I can't remember

exactly).

My page buffers are set to 10 000!!! I have set it up when I was
still using Firebird Superserver. Is this bad with classic? I have
lots of ram and it has never been fully used so far.

> 1) an accounting application. This app processes the transactions

in a batch

> way, and becouse of a bad design it was slowing down everything

when people

> got to start processing weeks of info. As soon the design was

reviewed and

> also bad triggers were re-written things got a lot better.

Are you saying that even with all these processors, when a slow
query is being executed it slows down everybody else? When multiple
processors doesn't it make sense that the other connections will run
as if they are alone (if the number of CPUs is enough of course)

> 2) We also had to much 'lock conflics' and we solve that (at a

performance

> point of view) by raising the related configuration at

firebird.conf -- that

> helped A LOT.

Please tell me which configuration parameter helped a lot, I am
really interested! Would it be possible to send your firebird.conf
here?

> 3) Another thing we had to 'take care' was some bad codes that

were

> 'raising' the gap bettween OIT and OAT. Sometimes we had huge

difference

> between them and things got quite slow.

Hoes does the gap affect performance? Where can I read about it (I
know what it is, but I am not sure why it affects performance badly)

> Really, the only bad thing we found using this setup was that it

seems

> 'dead' clients never get their fb_inet_server released. We've

already

> changed the default on windows from 2 hours to something small

(few minutes)

> but did not see any effect at all -- thats realy annoying -- and

can be

> sometimes a problem. =)

Yes, I have the same problem. If someone connects to the database
and their computer crashes or a switch goes down (due to a power
surge for example) their connection stays on forever. The only way
to free it, that I have found, is to kill the relevant firebird
instance, but I am seriously afraid that this might damage the
database (even though the CPU is at 0% when I do it). Is there a
better way to kill such a process? How about SuperServer, where you
only have one EXE, how do you kill a specific connection?

If it stays on forever it might even keep a transaction open which
will cause the gap between OAT and OIT to increase and increase....

> Well, I know this is not exactly what you're looking for but I

home this info helps get some idea.

Yes, defenitely, thanks!