Bug #43487 Change THR_LOCK_myisam to use MY_MUTEX_INIT_FAST
Submitted: 8 Mar 2009 19:46 Modified: 7 Jul 2009 6:26
Reporter: Mark Callaghan Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: MyISAM storage engine Severity:S5 (Performance)
Version:5.0,5.1 OS:Any
Assigned to: CPU Architecture:Any
Tags: mutex, myisam, THR_LOCK_myisam

[8 Mar 2009 19:46] Mark Callaghan 
Description:
Concurrent workloads for MyISAM are faster when THR_LOCK_myisam is initialized with MY_MUTEX_INIT_FAST instead of MY_MUTEX_INIT_SLOW. 

Results from:
* sysbench readonly with --oltp-secondary-index patch from me
* 16 core server using Linux 2.6 and x86_64
* numbers from 1,2,4,8,16,32, 64 concurrent sessions
* 2M rows in sbtest table

Throughput (number from transactions: line in sysbench output)
 242  499  834 1060  875  725  618 -- 5.0.75 unmodified
 247  511  841 1132  906  754  667 -- 5.0.75 with suggested change

How to repeat:
na

Suggested fix:
Get rid of MY_MUTEX_INIT_SLOW
[9 Mar 2009 13:09] MySQL Verification Team 
Thank you for the bug report.
[10 Mar 2009 14:34] Sergey Vojtovich 
Rather a trivial fix (one line), but we need to figure out reasons for initializing THR_LOCK_myisam as slow.
[10 Mar 2009 15:07] Mark Callaghan 
I think it gets more interesting than that. You need to determine why this and other mutexes use MY_MUTEX_INIT_SLOW. One or more mutexes used for replication code in log.cc also use SLOW.
[19 Mar 2009 17:09] Mark Callaghan 
For another data point, I changed LOCK_event_loop and LOCK_thd_add to use MY_MUTEX_INIT_FAST and sysbench readonly throughput was 10% better for a 16-core server with 16 concurrent users, thread_handling=pool-of-threads and thread_pool_size=20.

The current choice of NULL, MY_MUTEX_INIT_FAST or MY_MUTEX_INIT_SLOW in pthread_mutex_init calls appears somewhat random. And if it isn't random, comments in the code sure would be nice.