Hi list!

We have a customer with a poor performance today. I take a look and discover
that the HDD is very busy, then I run a fb_lock_print of that database and
it shows:

Mutex wait: 37.6%

Hash slots: 1009, Hash lengths (min/avg/max): 74/ 98/ 128



Terrible numbers. Then I disconnect everything, chang LockHashSlots in
Firebird.conf to 4093 (more or less 4 times more that default 1009 and still
a prime number) and now the HDD is running smoth!

Now fb_lock_print shows:

Mutex wait: 15.9%

Hash slots: 4093, Hash lengths (min/avg/max): 5/ 18/ 33



Much better but still worst. I planning to change it again to 8000+-. And I
hope I can get a mutex wait < 5%.

Well, what is the drawback of using a high LockHashSlots? More than the
default 1009?



Environment:



Windows Server 2008

Firebird Classic 2.5.1 64 bits

Ram size: 16Gb

Database Size: 13.2Gb

Concurrent simultaneous users: 118

Cached pages: 2000 for each connection (it was 90 some time ago, we
increased this value because low insert operations in large tables with 12+
indices. I think the problem became more obvious when we increase this value
- Ann told in and old mail that every cached page uses hash slots)



Thanks!



[Non-text portions of this message have been removed]