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 <kniel...@knielsen-hq.org>wrote: > Laurynas Biveinis <laurynas.bivei...@gmail.com> 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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~maria-developers > More help : https://help.launchpad.net/ListHelp > -- Mark Callaghan mdcal...@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
