It would seemingly be a reasonable idea to have an option to lock certain plugins in a "permanent" loaded state, so that they cannot be unloaded at runtime, but all of that per-entry locking can be avoided with e.g. if (!plugin->permanent) checks for the lock/unlock. Then, a server restart would be required to unload the plugin.

Regards,

Jeremy


On Mon, Aug 19, 2013 at 10:44 AM, Pavel Ivanov <pivanof@google.com> wrote:
No, it's not reasonable for semi-sync to lock/unlock LOCK_plugin. It's
plugin infrastructure that does that.

I've actually was terrified to learn that each call into semi-sync
plugin is surrounded with pthread_rwlock_rdlock/pthread_rwlock_unlock
(which is not cheap I believe). And also for each such call it
"locks"/"unlocks" the semi-sync plugin. And although "locking" plugin
avoids locking LOCK_plugin when plugin is linked statically,
"unlocking" doesn't do that. And with all that calls into semi-sync
plugin happen I believe twice for each COMMIT and twice for each
binlog event sent to each slave.
I'd say that's a big performance hog...

On Mon, Aug 19, 2013 at 8:27 AM, MARK CALLAGHAN <mdcallag@gmail.com> wrote:
> Is it reasonable for semi-sync to need to lock/unlock LOCK_plugin that
> frequently? The plugin architecture, like most of the rest of MySQL, wasn't
> described to people on the outside (like me).
>
>
> On Mon, Aug 19, 2013 at 6:32 AM, Pavel Ivanov <pivanof@google.com> wrote:
>>
>> On Mon, Aug 19, 2013 at 5:17 AM, Roberto Spadim <roberto@spadim.com.br>
>> wrote:
>> > hi!
>> >
>> >> 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.
>> >>
>> >
>> > Should the
>> > "SET GLOBAL query_response_time_stats=0"
>> > solve this contention problem? or the LOCK_plugin is called always,
>> > doesn't matter if it's "disabled" or not?
>>
>> If it's implemented the same way as semisync plugins (and it should be
>> implemented like that) then LOCK_plugin is locked even when plugin's
>> functionality disabled, because it gets disabled using plugin-specific
>> variable which can be checked only inside the plugin code.
>>
>>
>> Pavel
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~maria-developers
>> Post to     : maria-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~maria-developers
>> More help   : https://help.launchpad.net/ListHelp
>
>
>
>
> --
> Mark Callaghan
> mdcallag@gmail.com

_______________________________________________
Mailing list: https://launchpad.net/~maria-developers
Post to     : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp