maria-developers team mailing list archive

[MARK CALLAGHAN <mdcallag@xxxxxxxxx>]

Laurynas - I am surprised they are still iterating on
http://bugs.mysql.com/bug.php?id=71708. Assuming another big change is
needed I think that will be version 4 for that code.


On Wed, Apr 30, 2014 at 5:59 AM, Kristian Nielsen
<knielsen@xxxxxxxxxxxxxxx>wrote:

> Laurynas Biveinis <laurynas.biveinis@xxxxxxxxx> writes:
>
> > Did you test InnoDB or XtraDB?
>
> It should be XtraDB, which is the default in MariaDB 10 now.
>
> This is the version info from univ.i:
>
>     #define INNODB_VERSION_MAJOR    5
>     #define INNODB_VERSION_MINOR    6
>     #define INNODB_VERSION_BUGFIX   15
>
>     #ifndef PERCONA_INNODB_VERSION
>     #define PERCONA_INNODB_VERSION 63.0
>     #endif
>
> > The affected waits are those that go to wait on events in the sync
> > array(s). No global mutex is used if locking is completed through
> > spinning.
>
> > We have implemented priority mutex/rwlocks in XtraDB for a different
> > issue, but it indirectly helps here: allow high priority waiters
> > waiting on their own designated event. When the mutex/rwlock is
> > released, signal high-priority waiters only,  There are much fewer
> > higher priority waiter threads than regular ones.
>
> We also have the innodb_thread_concurrency. All of these seem to be
> work-arounds for the fundamental problem that InnoDB locking primitives are
> fundamentally non-scalable. The global mutex on the sync arrays is bad
> enough,
> but wake-all is a real killer, as it creates O(N**2) cost of having N
> threads
> waiting on the same lock.
>
> But of course, this is the view of an outsider. I appreciate that the
> issue is
> much more complex once one gets down to the real code. The locking
> primitives
> are the very core of a complex legacy codebase. And the InnoDB locking
> primitives provide a lot of status information to the DBA that would not be
> available from a simple pthread_mutex_t.
>
> > dict_mem_table_create() creating mutexes and rwlocks all the time is a
> > known issue: http://bugs.mysql.com/bug.php?id=71708. It was here
> > forever, made worse in Oracle 5.6.16, fully fixed in Percona 5.6.16.
> > Oracle should have a partial fix in 5.6.19 and full in 5.7.
>
> Ah, nice, thanks for the pointer!
>
> >> I wonder if the InnoDB team @ Oracle is doing something for this in
> 5.7? Does
> >> anyone know? I vaguely recall reading something about it, but I am not
> sure.
> >
> > 5.7 allows different mutex implementations to co-exist, and there is a
> > new implementation that uses futexes. The sync array implementation is
> > still there too. The code pushed so far seems to focus on getting the
> > framework right and adding implementations more than on performance.
> > I'd expect that to change in the later pushes.
>
> Ok, so that sounds promising.
>
> >> It would seem a waste to duplicate their efforts.
> >
> > There are Percona's efforts too ;)
>
> Indeed! I wouldn't want to duplicate any of that effort, though with
> Percona's
> effort it's a lot easier due to better communication.
>
> It seems that you great people at Percona have a good handle on the InnoDB
> issues, together with whatever the Oracle InnoDB team might come up with,
> so
> it makes sense for me to focus on other stuff. Though it still makes me
> cry to
> look at that sync array code in InnoDB...
>
> Thanks,
>
>  - Kristian.
>
> _______________________________________________
> 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