Bug #71727 | Follow up work on Bug#16249481- INNODB DOES NOT SCALE WELL ON 12 CORE ... | ||
---|---|---|---|
Submitted: | 14 Feb 2014 23:30 | Modified: | 28 Feb 2014 10:24 |
Reporter: | Inaam Rana (OCA) | Email Updates: | |
Status: | Analyzing | Impact on me: | |
Category: | MySQL Server: InnoDB storage engine | Severity: | S5 (Performance) |
Version: | 5.6.16 | OS: | Any |
Assigned to: | Assigned Account | CPU Architecture: | Any |
[14 Feb 2014 23:30]
Inaam Rana
[18 Feb 2014 11:57]
Laurynas Biveinis
Inaam - I also have some concerns about the prev_bpage pointer, but different from yours. First, I think that the scenario you describe (neighbor flush flushes and removes the prev_bpage page from the LRU list) should be very rare indeed, since LRU flushes do not remove the pages from the LRU list, only evictions do, thus for it to occur we need a single page LRU flush going in parallel. Second, I am worried that on the overloaded server the prev_bpage page may become young meanwhile. Then page cleaner resumes and flushes it, while it shouldn't have. If more pages manage to become young at the same time, then the page cleaner ends up flushing the wrong end of the LRU list in that iteration, unless I'm missing something.
[18 Feb 2014 13:45]
Inaam Rana
Laurynas, You are right. I confused 5.6 with 5.7 where flushing and eviction happens in a single step. Your concern about prev_bpage moving to MRU end seems valid but given its unlikeliness my guess is that we should be able to live with it.
[28 Feb 2014 10:24]
Arnaud Adant
Thanks Inaam for this suggestion. Do you have a test case to prove that it is an issue on some work loads ?
[5 Mar 2014 0:31]
Sunny Bains
Inaam, as an experiment I tried this patch on 5.7: === modified file 'storage/innobase/buf/buf0buddy.cc' --- storage/innobase/buf/buf0buddy.cc revid:bjorn.munch@oracle.com-20140303171910-l7kxafmxk1xb3mno +++ storage/innobase/buf/buf0buddy.cc 2014-03-05 00:23:32 +0000 @@ -590,6 +590,8 @@ buf_buddy_relocate( return(false); } + rw_lock_x_unlock(hash_lock); + /* The block must have been allocated, but it may contain uninitialized data. */ UNIV_MEM_ASSERT_W(src, size); @@ -605,9 +607,8 @@ buf_buddy_relocate( ut_a(bpage->zip.data == src); memcpy(dst, src, size); - bpage->zip.data = reinterpret_cast<page_zip_t*>(dst); - rw_lock_x_unlock(hash_lock); + bpage->zip.data = reinterpret_cast<page_zip_t*>(dst); mutex_exit(block_mutex); It made some difference in the test. An in-memory Sysbench OLTP RW @64 threads with an 8K key block size. Server was a 16 physical core, with Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz. The hash_lock is the bottleneck in the test with and without this patch. There is some room I think to improve this code. Regarding the other points, looks like you two have cancelled out each others concerns :-)
[30 Jan 2022 21:54]
Roel Van de Paar
Analyzing since 2014?