Issue Details (XML | Word | Printable)

Key: CORE-2591
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dmitry Yemanov
Reporter: Dmitry Yemanov
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.
Firebird Core

High mutex wait ratio and degraded performance after some time of performing normally

Created: 13/Aug/09 07:00 AM   Updated: 07/Aug/16 01:09 PM
Component/s: Engine
Affects Version/s: 2.5 Alpha 1, 2.1.1, 2.0.5, 2.1.2, 2.5 Beta 1, 2.5 Beta 2
Fix Version/s: 2.5 RC1, 2.0.6, 2.1.4

Environment: Classic Server

QA Status: Cannot be tested

 Description  « Hide
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.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
There are no comments yet on this issue.