12.03.2017 00:12, 'Leyne, Sean' wrote:
>
> Am I right to think that I need to create a process to run the command on a
> regular basis (every 5 secs?) to find what objects locks are waiting for?
Yes. But we're still guessing in the dark, the reason of the slowdown
could be completely unrelated
> > I asked for -w, not -iw.
>
> Or maybe -o -w, if just -w prints nothing.
FYI, -w prints the same basic details
-w -o prints some details -- reading Helen's book to understand what it is
reporting.
Am I right to think that I need to create a process to run the command on a
regular basis
11.03.2017 23:56, Dmitry Yemanov wrote:
>
> I asked for -w, not -iw.
Or maybe -o -w, if just -w prints nothing.
Dmitry
++
Visit
11.03.2017 22:40, 'Leyne, Sean' wrote:
>
> Here are some initial results
>
> C:\FIREBIRD\bin>fb_lock_print.exe -d x -iw 1 5000
I asked for -w, not -iw.
Dmitry
> Too many deadlock scans, it means long (> 10 sec) waiting for some locks.
> Regular (every few minutes) fb_lock_print -w output could probably shed
> some light...
Here are some initial results
C:\FIREBIRD\bin>fb_lock_print.exe -d x -iw 1 5000
01:08:29wait/s reject/s timeout/s
11.03.2017 21:03, 'Leyne, Sean' wrote:
>
>>> 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.
>
> Is the engine that smart to trim to an exact prime number?
Nope, 65521
> > 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.
Is the engine that smart to trim to an exact prime number?
> > Now, today, I checked the lock print values again,
10.03.2017 23:58, 'Leyne, Sean' wrote:
>
> 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.
> Yesterday, I ran fb_lock_print to check on the database and found a
> “Mutex wait”
