> > OWNER BLOCK 732776
> > Owner id: 114332029419524, type: 1, pending: 0
> > Process id: 26620 (Alive), thread id: 2348
> > Flags: 0x08 wake
> > Requests (431): forward: 732888, backward: 10111616
> > Blocks: *empty*
> > 732776 waits on nothing.
> >
> >
14.03.2017 20:54, 'Leyne, Sean' wrote:
>
> The -o -w switches generated details such as:
>
> OWNER BLOCK 732776
> Owner id: 114332029419524, type: 1, pending: 0
> Process id: 26620 (Alive), thread id: 2348
> Flags: 0x08 wake
> Requests (431): forward: 732888,
Dmitry,
> > 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 to the lock manager (e.g.
> > 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
That's fine, that is at least a path to investigate...
>, the reason of the slowdown could
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”
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
13 matches
Mail list logo
