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