maria-developers team mailing list archive
-
maria-developers team
-
Mailing list archive
-
Message #06071
Re: MariaDB mutex contention
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
Follow ups
References