> > 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
