Issue Details (XML | Word | Printable)

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

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

Incorrect (zero) values are reported for "acquire blocks" and "mutex wait" counters in the fb_lock_print output

Created: 05/Dec/11 07:57 AM   Updated: 23/Apr/13 01:28 PM
Component/s: Engine, LOCK_PRINT
Affects Version/s: 3.0 Initial, 2.5.0, 2.5.1
Fix Version/s: 2.5.2, 3.0 Alpha 1

Time Tracking:
Not Specified

Environment: SuperServer and SuperClassic

Planning Status: Unspecified


 Description  « Hide
When accessing the lock table, the local mutex is acquired first and only then the shared mutex is acquired. If all the connections belong to the single address space (SS and SC architectures), all the contention is on the local mutex, not on the shared mutex. But the local mutex "blocks" are not encounted in the statistics, hence both "acquire blocks" and "mutex wait" counters will be always zero in this case, making it hard to analyze the possible performance bottlenecks (this is mostly true for SC, as SS is almost never LM bound).

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