Incorrect (zero) values are reported for "acquire blocks" and "mutex wait"
counters in the fb_lock_print output
---------------------------------------------------------------------------------------------------------------
Key: CORE-3686
URL: http://tracker.firebirdsql.org/browse/CORE-3686
Project: Firebird Core
Issue Type: Bug
Components: Engine, LOCK_PRINT
Affects Versions: 2.5.1, 2.5.0, 3.0 Initial
Environment: SuperServer and SuperClassic
Reporter: Dmitry Yemanov
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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
