Bug #38924 LOCK_mdl needs to cool down
Submitted: 20 Aug 2008 20:21 Modified: 13 Dec 2010 14:56
Reporter: Neel Nadgir Email Updates:
Status: Can't repeat Impact on me:
None 
Category:MySQL Server: Locking Severity:S5 (Performance)
Version:6.0.7-alpha OS:Any
Assigned to: Alexey Stroganov CPU Architecture:Any
Tags: mdl, performance

[20 Aug 2008 20:21] Neel Nadgir
Description:
LOCK_mdl is hot for simple sysbench read-only benchmarks. Instrumenting the code with timing calls shows that around 10% of the query execution time is spent acquiring LOCK_mdl. 

How to repeat:
Build mysql 6.0.7-alpha, and instrument calls to acquire and release LOCK_mdl in sql/mdl.cc. Then run sysbench readonly test on a system with > 8 cpus with threads > number of cpus. Alternatively (on opensolaris), you can estimate time taken by mdl_acquire_shared_lock() using dtrace, or get a rough estimate of the contention using plockstat.
[17 Sep 2009 9:47] Philip Stoev
Ranger, kindly please take ownership over this benchmarking issue related to sysbench and metadata locking. Please try to repeat this bug and obtain a performance profile. In addition, Kostja said the following:

(12:44:56 PM) kostja: I need a profile, though.
(12:45:11 PM) kostja: I would like to understand what action to take:
(12:45:18 PM) kostja: - to reduce the body of the critical section
(12:45:21 PM) kostja: - to add spin loops
(12:45:27 PM) kostja: - to split the mutex
(12:45:30 PM) kostja: and so and so
(12:45:43 PM) kostja: and I need to understand how critical it is:
(12:45:51 PM) kostja: is the situation, overall, worse or better than in 5.1?
(12:46:04 PM) kostja: adding this information to the bug report
[20 Jan 2010 10:17] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/97520

3057 Konstantin Osipov	2010-01-20
      Bug#46272/Bug#38924 review fixes in progress.
      Rename a few members, realign comments to fit 66 characters, 
      update comments.
[20 Jan 2010 10:42] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/97529

3058 Konstantin Osipov	2010-01-20
      Bug#46272/Bug#38924 review fixes in progress.
      Update MDL_key class to be more compact.
      Simplify the comparison method, used when sorting MDL_keys.
[20 Jan 2010 11:20] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/97535

3059 Konstantin Osipov	2010-01-20
      Bug#46272/Bug#38924 review fixes in progress.
      Misc fixes.
[20 Jan 2010 12:31] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/97548

3060 Konstantin Osipov	2010-01-20
      Bug#46272/Bug#38924 review fixes in progress.
      Introduce class MDL_map to hold all MDL locks
      taken in the server.
[20 Jan 2010 13:44] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/97578

3061 Konstantin Osipov	2010-01-20
      Bug#46272/Bug#38924 review fixes in progress.
      Misc. fixes.
[13 Dec 2010 14:56] Dmitry Lenev
Hello!

LOCK_mdl mutex was removed in a pre-requisite patch for bug #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock" and bug #37346 "innodb does not detect deadlock between update and alter table". This patch has changed MDL subsystem to use mutex per lock and condition variable per context instead of one mutex and one conditional variable for the whole subsystem. The closest thing to LOCK_mdl which we have now is MDL_map::m_mutex lock hasn't shown to be very hot.

Thus I'm closing this report as "Can't repeat" as issue is no longer repeatable.

Any performance bottlenecks related to new implementation should be reported separately.