>>1) We do monitor the transaction gab and if needed, we interact.
how often and how? By MON$ tables or you read header page?
>>2) We do run gbak daily. We do not use nbackup - we would like to and tried
>>it but it's corrupting the db.
and this slowdown is not in time of backup i suppose?
> 1) We have sweep set to 0. We do monitor the transaction gab and if
> needed, we interact. Any kind of automatic sweep under high load will kill
> the server :)
1- Do you run a manual sweep on a regular basis?
2- What is the CPU % like when Firebird "slows down"?
3- Have you tried using
We splitted our system now to 2 databases, reducing the connections to about
250 per DB.
Running on same Hardware (same SAN-Storage) and splitted the CPU ressources.
Both system seems stable now, but that's not really a solution we prefered.
Just helps us to not lose customers at the
1) We have sweep set to 0. We do monitor the transaction gab and if needed, we
interact. Any kind of automatic sweep under high load will kill the server :)
2) We do run gbak daily. We do not use nbackup - we would like to and tried it
but it's corrupting the db.
3) We do use read-only
Hey Thomas,
thanks for your extensive reply.
Unfortunatly we'r still bound to some old 32bit UDF functionality which we
can't get in 64bit.
I think you know about the use of SuperClassic with 32bit Server - 2GB RAM
Limit :)
It's not impossible, but also not really a fast route we can go. But
Hey Alexey,
thanks you for our input. I think what you say is correct, and we reviewed our
disk setup again.
We are utilizing mechnical discs so it's kinda hard to compare SSD performance
to them.
But they should provide enought IOPS for our load.
Unfortunatly we can't just switch to a single