Hi Sean,
this is the one thing I am getting when I am connecting to the database.
I am not the one working productively on the system, so I can't really
tell wether this has become faster or is still the same.
LOCK_HEADER BLOCK
Version: 145, Active owner: 0, Length: 7048576, Used: 540536
Flags: 0x0001
Enqs: 5031, Converts: 113, Rejects: 8, Blocks: 11
Deadlock scans: 0, Deadlocks: 0, Scan interval: 10
Acquires: 7695, Acquire blocks: 3, Spin count: 0
Mutex wait: 0.0%
Hash slots: 30011, Hash lengths (min/avg/max): 0/ 0/ 4
Remove node: 0, Insert queue: 0, Insert prior: 0
Owners (3): forward: 252920, backward: 490968
Free owners: *empty*
Free locks (5): forward: 254960, backward: 519480
Free requests (6): forward: 540344, backward: 403464
Lock Ordering: Enabled
This is what the fb_lock_print output looks like.
Andreas
On 27.02.2017 00:25, Andreas Zeller zel...@lux-medien.com
[firebird-support] wrote:
>
>
> Hi Sean,
>
> that's what I am saying. It never really is 'under load'. It is just
> taking forever to select a clients data-page.
>
> I would blame bad design and shrug it off, but this was way faster on
> the ancient w2k server, so I have no idea where it gets stuck.
>
> Andreas
>
>
> On 26.02.2017 23:54, 'Leyne, Sean' s...@broadviewsoftware.com
> [firebird-support] wrote:
>>
>>
>>
>>
>> > Sean: fb_lock_print seems to have some trouble:
>> >
>> > Unable to access lock table.
>> > operating system directive shmem_data->sh_mem_length_mapped is 0
>> > failed -Success
>> >
>> > This is what I am getting from fb_lock_print -d filename.db0
>>
>> You need to specific the full/local path to the database and as well
>> as the database filename.
>>
>> You really want to look at the fb_lock_print numbers when the
>> database/server is under load.
>>
>> Sean
>>
>
>
