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

 

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' Sean@... [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