I forgot to add, the disk subsystem that the database running on supports 200,000+ 8KB IOPS, so slow disk performance is not likely.

> We have a client with 320GB database (running FB CS v2.5) reporting
> performance issues, while we are investigating possible application sources, I
> have been reviewing their Firebird config.
>
> Yesterday, I ran fb_lock_print to check on the database and found a "Mutex
> wait" value of 20.9%, which I knew that a "bad thing".  So, I increased (by
> 50%) the "Hash slots" value from 60011 to 90001.
>
> Now, today, I checked the lock print values again, and got even worse
> numbers!!!
>
>         LOCK_HEADER BLOCK
>                 Version: 145, Active owner:      0, Length: 67108864, Used: 32723368
>                 Flags: 0x0001
>                 Enqs: 712175161, Converts: 9327661, Rejects: 1440802, Blocks:
> 15963765
>                 Deadlock scans:      9, Deadlocks:      0, Scan interval:  10
>                 Acquires: 1133127873, Acquire blocks: 256464312, Spin count:   0
>                 Mutex wait: 22.6%
>                 Hash slots: 90001, Hash lengths (min/avg/max):    0/   0/   5
>                 Remove node:      0, Insert queue:      0, Insert prior:      0
>                 Owners (288):   forward: 732776, backward: 29775680
>                 Free owners (400):      forward: 9817904, backward: 9548560
>                 Free locks (28162):     forward: 20344528, backward: 18378944
>                 Free requests (293517): forward: 7727280, backward: 23127520
>                 Lock Ordering: Enabled
>
>
> Any suggestions on how I can improve the numbers?
>
> Thanks in advance
>
> Sean
>