maria-developers team mailing list archive
-
maria-developers team
-
Mailing list archive
-
Message #06108
Re: MariaDB mutex contention
I guess sometimes yes, having statically linked plugins is a
workaround for mutex contention. But it's not the case for semi-sync
plugins.
On Tue, Aug 20, 2013 at 10:11 AM, MARK CALLAGHAN <mdcallag@xxxxxxxxx> wrote:
> Mutex contention from various plugins
>
>
> On Tue, Aug 20, 2013 at 9:12 AM, Pavel Ivanov <pivanof@xxxxxxxxxx> wrote:
>>
>> Workaround for which problem?
>>
>> On Tue, Aug 20, 2013 at 8:17 AM, MARK CALLAGHAN <mdcallag@xxxxxxxxx>
>> wrote:
>> > Is the workaround to use static rather than dynamic plugins?
>> >
>> >
>> > On Tue, Aug 20, 2013 at 7:31 AM, Sergei Golubchik <serg@xxxxxxxxxxx>
>> > wrote:
>> >>
>> >> Hi, Pavel!
>> >>
>> >> On Aug 20, Pavel Ivanov wrote:
>> >> > On Tue, Aug 20, 2013 at 1:09 AM, Sergei Golubchik <serg@xxxxxxxxxxx>
>> >> > wrote:
>> >> > > On Aug 19, Pavel Ivanov 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.
>> >> > >
>> >> > Sure, but macro FOREACH_OBSERVER inside rpl_handler.cc doesn't use
>> >> > this function. It uses plugin_unlock_list() which always locks
>> >> > LOCK_plugin.
>> >> >
>> >> > BTW, MariaDB still supports compiling semi-sync plugins dynamically,
>> >> > but it seems that it doesn't do anything against unloading semi-sync
>> >> > plugins in the middle of transactions. Did anyone think about this?
>> >>
>> >> Judging from the replication plugin API - I don't think so.
>> >>
>> >> But if it adds that much overhead, I suppose we'll need to fix it.
>> >> Then we fix the unloading too.
>> >>
>> >> Regards,
>> >> Sergei
>> >>
>> >> _______________________________________________
>> >> Mailing list: https://launchpad.net/~maria-developers
>> >> Post to : maria-developers@xxxxxxxxxxxxxxxxxxx
>> >> Unsubscribe : https://launchpad.net/~maria-developers
>> >> More help : https://help.launchpad.net/ListHelp
>> >
>> >
>> >
>> >
>> > --
>> > Mark Callaghan
>> > mdcallag@xxxxxxxxx
>
>
>
>
> --
> Mark Callaghan
> mdcallag@xxxxxxxxx
References
-
MariaDB mutex contention (was: Re: MariaDB 10.0 benchmarks on upcoming IVB-EP processors ...)
From: Axel Schwenke, 2013-08-16
-
Re: MariaDB mutex contention (was: Re: MariaDB 10.0 benchmarks on upcoming IVB-EP processors ...)
From: Sergey Vojtovich, 2013-08-17
-
Re: MariaDB mutex contention (was: Re: MariaDB 10.0 benchmarks on upcoming IVB-EP processors ...)
From: Pavel Ivanov, 2013-08-17
-
Re: MariaDB mutex contention
From: Axel Schwenke, 2013-08-19
-
Re: MariaDB mutex contention
From: Roberto Spadim, 2013-08-19
-
Re: MariaDB mutex contention
From: Pavel Ivanov, 2013-08-19
-
Re: MariaDB mutex contention
From: MARK CALLAGHAN, 2013-08-19
-
Re: MariaDB mutex contention
From: Pavel Ivanov, 2013-08-19
-
Re: MariaDB mutex contention
From: Sergei Golubchik, 2013-08-20
-
Re: MariaDB mutex contention
From: Pavel Ivanov, 2013-08-20
-
Re: MariaDB mutex contention
From: Sergei Golubchik, 2013-08-20
-
Re: MariaDB mutex contention
From: MARK CALLAGHAN, 2013-08-20
-
Re: MariaDB mutex contention
From: Pavel Ivanov, 2013-08-20
-
Re: MariaDB mutex contention
From: MARK CALLAGHAN, 2013-08-20