You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the system is highly loaded for a long time, some operations may perform worse as compared to a recently restarted server (and the lock manager). This situation is coupled with a unexpectedly high mutex wait ratio in the fb_lock_print output.
The lock table has many double linked lists that represent the various run-time objects: resources, requests, owners, etc. All operations with these lists are usually very fast (complexity O(1)), but allocation of a new lock resource requires scanning the total list of unused locks in order to find a best match for the given lock key size. This raises the complexity up to O(N) in the worst case. Recent FB versions have introduced more locks per server process, e.g. DSQL cache locks and index page GC locks, thus increasing the total number of locks in the lock table as well as the average number of unused locks in the list. So this issue becomes more visible nowadays.
Submitted by: @dyemanov
When the system is highly loaded for a long time, some operations may perform worse as compared to a recently restarted server (and the lock manager). This situation is coupled with a unexpectedly high mutex wait ratio in the fb_lock_print output.
The lock table has many double linked lists that represent the various run-time objects: resources, requests, owners, etc. All operations with these lists are usually very fast (complexity O(1)), but allocation of a new lock resource requires scanning the total list of unused locks in order to find a best match for the given lock key size. This raises the complexity up to O(N) in the worst case. Recent FB versions have introduced more locks per server process, e.g. DSQL cache locks and index page GC locks, thus increasing the total number of locks in the lock table as well as the average number of unused locks in the list. So this issue becomes more visible nowadays.
Commits: e5a70ba 3a278cf 3f6dd2b
The text was updated successfully, but these errors were encountered: