Faisal Abdullah wrote:

> Hi Ann,
>
> Thanks for the lengthy reply.
> I can't find gds_lock_print, but there is an fb_lock_print

Right. That's what I wanted. V1.5 started a serious migration from
Borland and older names (gds, isc) to Firebird names. I often slip up
and use old terminology.

>
> I did a fb_lock_print -a > file.txt and its huge (100M, a bzip2 is 9.2 M).
> So i'll paste the min/max/average here:

Thanks. There's also a switch for getting only the lock header dump,
which I should have found for you, but having you edit down the results
is much appreciated.

> Also, we have this in firebird.conf: LockMemSize = 262144

Good.

>
> Deadlock scans: 409, Deadlocks: 36, Scan interval: 10

The line above indicates that the system is running pretty well -
deadlock scans occur when a processes has waited 10 seconds for a lock
and a large number of deadlock scans suggests that some threads aren't
responding to requests to downgrade locks.

> Acquires: 1695164426, Acquire blocks: 346427030, Spin count: 0

That's pretty busy.

> Mutex wait: 20.4%

That's very high, but there's nothing to be done about it from the
client side.

> Hash slots: 2048, Hash lengths (min/avg/max): 24/ 31/ 43

That's a problem. You've got the maximum number of hash slots and
you've still got long chains. Just out of curiosity, how many page
buffers are you using? Each page buffer in use is a lockable object,
thus a lock block and a hash table entry.


The rest of the information looks good. We should increase the default
lock table size and the maximum allowable number of hash slots.

Thanks,


Ann