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.