Ferda Brabenec wrote:

>
> Lets say that I have 5 parallel queries. 5 connections serially
> feeding queries to the server. Then I would expect something
> like 10 times longer processing time for any query than in single
> connection case, but not 100x - 1000x longer. Of course there will
> always be fluctuations in processing times, but 2+ seconds for
> a simple ODBC call seems to me more like kind of temporary deadlock.
> FB engine gurus: am I wrong?
>

Well, deadlocks are not temporary, and when resolved, they send a very
distinctive error back to the log (in the case of system deadlocks) or
the victim transactions (in the case of user deadlocks). The system
should be deadlock free, and, with the exception of increasing rare
bugs, it is.

Now as the the source of the problem. The normal cause of uneven poor
performance is delayed garbage collection on indexes with large numbers
of duplicates. Firebird changes the index code to avoid the problem,
but earlier versions get into a very high-cpu loop removing duplicates
from indexes if the duplicate chain is longer than about 10000 records.


Have you checked for that? Gstat -a -r produces a report that includes
the number of duplicates on a single value for each index (max dup).


Regards,


Ann