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 >
