Hi Pavel, Pavel Ivanov wrote:
From the above I'd say: 911 928 - number of executed queries (1x LOCK_tdc per query) 1 835 243 / 911 928= ~2 - LOCK_open was acquired 2x per query 4 194 896 / 911 928= ~4 - LOCK_plugin was acquired 4x per query
I wonder how the MariaDB under test was compiled and what flags were used. AFAIK by default semisync plugins are compiled in. That means that for each transaction ha_commit_trans() will execute
RUN_HOOK(transaction, after_commit, (thd, FALSE));
It involves locking of LOCK_plugin when semisync plugin is "unlocked" (even though it's compiled in statically). Also trans_commit() has this:
RUN_HOOK(transaction, after_commit, (thd, FALSE));
Which also involves locking of LOCK_plugin.
Good catch! Indeed the default cmake configuration activates semisync master and slave, while the release build explicitly disables those. Removing those two plugins greatly reduced contention of LOCK_plugin. Since the binlog was disabled for this benchmark, I regard this behavior a bug. Another plugin that should be disabled is QUERY_RESPONSE_TIME. It has quite some impact on LOCK_plugin: -DWITH_QUERY_RESPONSE_TIME=1 +-----------------------------------------+------------+-----------------+ | event_name | count_star | sum_timer_wait | +-----------------------------------------+------------+-----------------+ | wait/synch/mutex/sql/LOCK_open | 2743723 | 160451183703111 | | wait/synch/mutex/mysys/THR_LOCK::mutex | 2743651 | 19122327109683 | | wait/synch/mutex/sql/LOCK_plugin | 3135747 | 18611700478728 | | wait/synch/rwlock/sql/LOCK_tdc | 1356784 | 1360918935810 | -DWITHOUT_QUERY_RESPONSE_TIME=1 completely removes LOCK_plugin from the top 20 list. This is also considered a bug as the plugin API should be lightweight. XL