← Back to team overview

maria-developers team mailing list archive

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