Bug #43487 Change THR_LOCK_myisam to use MY_MUTEX_INIT_FAST
Submitted: 8 Mar 20:46 Modified: 7 Jul 8:26
Reporter: Mark Callaghan
Status: Verified
Category:Server: MyISAM Severity:S5 (Performance)
Version:5.0,5.1 OS:Any
Assigned to: Miguel Solorzano Target Version:
Tags: myisam, THR_LOCK_myisam, mutex
Triage: Triaged: D3 (Medium) / R3 (Medium) / E2 (Low)

[8 Mar 20: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 14:09] Miguel Solorzano 
Thank you for the bug report.
[10 Mar 15: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 16: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 18: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.