Planet MySQL Planet MySQL: Meta Deutsch Español Français Italiano 日本語 Русский Português 中文
The InnoDB Mutex, part 2
+2 Vote Up -0 Vote Down
I updated the innotsim client to include a new custom mutex from InnoDB in MySQL 5.7. This is called TTASFutexMutex in the source. I also fixed a bug in innotsim - the benchmark timer was started too soon so these results are more accurate than the original post.

The original post has much more detail on the tests. In the graphs below, TTASFutexMutex has the label inno futex and the old-style custom mutex that uses a sync array has the label inno syncarray. My updated conclusions are:
  • TTASFutexMutex is worse than pthread default when the lock hold duration is short but gets better as the lock hold duration is increased. I wonder if this conclusion will hold across Linux releases.
  • The InnoDB mutex that uses a sync array continues to show its dark side with high concurrency but is pretty good with lower concurrency.
  • I am not sure that pthread adaptive should be used at all. It is frequently worse, occasionally much worse and in the base case not much better than pthread default. But I am using glibc 2.12 which was released in 2010. I don't know yet whether my conclusions hold for a recent glibc release. Alas, this appears to be widely used by both InnoDB and non-InnoDB code in mysqld (grep for MY_MUTEX_INIT_FAST). I think more benchmark results are required to figure this out. It might help to have an option in my.cnf to prevent it from being used.

Graphs for 0 nsec lock hold



Graphs for 1000 nsec lock hold 



Graphs for 4000 nsec lock hold 





Votes:

You must be logged in with a MySQL account to vote on Planet MySQL entries. More information on PlanetMySQL voting.

Planet MySQL © 1995, 2014, Oracle Corporation and/or its affiliates   Legal Policies | Your Privacy Rights | Terms of Use

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.