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

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

Environment: SuperServer and SuperClassic

 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   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
There are no comments yet on this issue.