<<- fb_lock_print displays the following about the database:
LOCK_HEADER BLOCK
Version: 145, Active owner: 0, Length: 2097152, Used: 1335440
Flags: 0x0001
Enqs: 9993237, Converts: 93191, Rejects: 1417230, Blocks: 2
Deadlock scans: 0, Deadlocks: 0, Scan interval: 10
Acquires: 19972846, Acquire blocks: 0, Spin count: 0
Mutex wait: 0.0%
Hash slots: 1009, Hash lengths (min/avg/max): 0/ 2/ 7
Remove node: 0, Insert queue: 0, Insert prior: 0
Owners (38): forward: 20824, backward: 872088
Free owners (126): forward: 973360, backward: 728016
Free locks (370): forward: 852200, backward: 195936
Free requests (12425): forward: 614608, backward: 1230536
Lock Ordering: Enabled
Here I noted that the "rejects" field accounts for ~14% of "enqs"
field but unfortunately I don't know the exact meaning of these
values. I guess about 14% of the lock requests are rejected for some
reason but I might be completely wrong.
So the questions:
- How should the output of fb_lock_print interpreted in this case? Are
these numbers "wrong" in some sense? Can they be improved by some
parameter tuning?>>
Rejects = Lock requests that cannot be satisfied.... no big deal
No wait locks? Engine locks? I wouldn't worry about it.
Looking at your Lock Header - it looks fine. Your problem is elsewhere.
Paul Beach
IBPhoenix
