> > We have a client with 320GB database (running FB CS v2.5)
>
> Is it really so? FB does not support LockHashSlots more than 64K, it would
> truncate your 90001 down to 65521.

<SL> Is the engine that smart to trim to an exact prime number?

> > Now, today, I checked the lock print values again, and got even worse
> > numbers!!!
>
> The change didn't help, the reason is elsewhere. 21% vs 23% could be
> explained by e.g. printing the stats at 3PM and 5PM.

<SL> The stats were printed at 3am.

> And we don't know what was the mutex wait ratio before they reported the performance issues.

<SL> True, not something that came to mind for us to be monitoring.

> 688 peak connections. Is this expected? Could the load be growing recently?

<SL> Yes, that seems a reasonable value.

<SL> Growth? Can't really speak to that, the client system is accessible by a large number of users, their work activity has day of the week and seasonal variation.

<SL> Curious, how would the number of owners (even free owners) impact the lock manager?

<SL> Today's numbers are much worse, again. But the activity load is substantially lower (based on the "Enqs" and "Acquires" values).

LOCK_HEADER BLOCK
Version: 145, Active owner: 0, Length: 67108864, Used: 5269256
Flags: 0x0001
Enqs: 202113295, Converts: 934229, Rejects: 96674, Blocks: 615455
Deadlock scans: 103, Deadlocks: 0, Scan interval: 10
Acquires: 326947224, Acquire blocks: 186433223, Spin count: 0
Mutex wait: 57.0%
Hash slots: 90001, Hash lengths (min/avg/max): 0/ 0/ 4
Remove node: 0, Insert queue: 0, Insert prior: 0
Owners (47): forward: 732776, backward: 2105384
Free owners (54): forward: 3893360, backward: 4041872
Free locks (6339): forward: 734616, backward: 2979632
Free requests (31952): forward: 2283760, backward: 1299072
Lock Ordering: Enabled

> > Any suggestions on how I can improve the numbers?

<SL> Would a larger/smaller page cache size have any impact? Currently = 400

<SL> Could reducing the cached pages increase lock operations performance?


Sean