Details
Major
Description
According to my benchmarks, normal mutexes scale better than adaptive at high thread count. At low thread count they behave similarly.
LOCK_open and THR_LOCK::mutex are the hot-path mutexes and thus are mostly affected.
See also:
http://svoj-db.blogspot.ru/2014/02/mariadb-mutexes-scalability.html
http://svoj-db.blogspot.ru/2014/02/mariadb-mutexes-scalability-continued.html
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
just for the record (to repeat my email and your reply):
> To summarize Axel results: > at low concurency normal can be ~1% slower. > at high concurrency r/o - normal are up to 25% faster. > at high concurrency r/w - normal are up to 10% slower. > > That last result bothers me a litte. Indeed. I'll check with Axel about it. Thanks for pointing it out!
Axel, please benchmark suggested patches and assign back to me.
I duplicated this task as TODO-629. Please check there for results.
Work will continue here. I'll close TODO-629
This is the patch that I tested vs. MariaDB-10.1.6
diff -urb mariadb-10.1.6/mysys/thr_lock.c mariadb-10.1.6-MDEV5755/mysys/thr_lock.c
--- mariadb-10.1.6/mysys/thr_lock.c 2015-07-23 14:19:50.000000000 +0000
+++ mariadb-10.1.6-MDEV5755/mysys/thr_lock.c 2015-08-10 10:50:57.646421280 +0000
@@ -440,7 +440,7 @@
{
DBUG_ENTER("thr_lock_init");
bzero((char*) lock,sizeof(*lock));
- mysql_mutex_init(key_THR_LOCK_mutex, &lock->mutex, MY_MUTEX_INIT_FAST);
+ mysql_mutex_init(key_THR_LOCK_mutex, &lock->mutex, MY_MUTEX_INIT_SLOW);
lock->read.last= &lock->read.data;
lock->read_wait.last= &lock->read_wait.data;
lock->write_wait.last= &lock->write_wait.data;
Only in mariadb-10.1.6-MDEV5755/mysys: thr_lock.c.orig
diff -urb mariadb-10.1.6/sql/table_cache.h mariadb-10.1.6-MDEV5755/sql/table_cache.h
--- mariadb-10.1.6/sql/table_cache.h 2015-07-23 14:19:50.000000000 +0000
+++ mariadb-10.1.6-MDEV5755/sql/table_cache.h 2015-08-10 11:34:17.916394975 +0000
@@ -139,7 +139,7 @@
TDC_element *element= (TDC_element*) (arg + LF_HASH_OVERHEAD);
DBUG_ENTER("lf_alloc_constructor");
mysql_mutex_init(key_TABLE_SHARE_LOCK_table_share,
- &element->LOCK_table_share, MY_MUTEX_INIT_FAST);
+ &element->LOCK_table_share, MY_MUTEX_INIT_SLOW);
mysql_cond_init(key_TABLE_SHARE_COND_release, &element->COND_release, 0);
element->m_flush_tickets.empty();
element->all_tables.empty();
Here is the result that I got from running sysbench OLTP with a single table (8 mio rows, ram disk) on a Power8 VM with cores/40 threads:
# data set 01 -> 10.1.6 # data set 02 -> 10.1.6 w/ MDEV-5755 patch # read only #thd 01 02 1 828.19 829.39 10 5699.4 5659.1 20 6688.4 6680.2 40 8503.8 8347.5 80 8384.8 8300.2 160 8228.6 8158.4 320 8303.1 8186.1 640 8203.8 8073.7 # read/write #thd 01 02 1 616.98 623.61 10 3798.4 3761.7 20 4663.5 4635.2 40 6008.6 5957.2 80 6220.4 6137.7 160 6289.0 6216.4 320 6378.1 6271.0 640 6013.4 5884.1
Conclusion: normal mutexes are a bit slower than fast mutexes.
I shall repeat this benchmark on an Intel machine, but currently I don't have a sufficiently large machine avaiable.
And here is the result for the same benchmark running on a 4 core (8 threads) Intel machine.
# data set 01 -> 10.1.6 # data set 02 -> 10.1.6 w/ MDEV-5755 patch # read only #thd 01 02 1 927.17 920.52 4 3263.5 3266.8 8 4016.2 3250.7 16 4756.0 4797.8 32 4733.9 4725.9 64 4715.7 4685.5 128 4799.4 4794.5 256 4793.2 4785.7 # read/write #thd 01 02 1 694.81 695.74 4 2130.9 2132.4 8 2939.4 2938.8 16 3339.1 3359.7 32 3514.5 3499.6 64 3683.5 3668.8 128 3789.1 3723.0 256 3741.5 3740.9
Again the performance is a bit worse with slow mutexes. Conclusion: keep the fast mutexes.
Locking scheme has changed a lot since this analysis was performed, so we can assume this task is not relevant anymore.
Sergei, please review patch for this task.