Bug #70216 | Unnecessary overhead from persistent adaptive hash index latches | ||
---|---|---|---|
Submitted: | 2 Sep 2013 12:42 | Modified: | 14 Oct 2014 23:23 |
Reporter: | Alexey Kopytov | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: InnoDB storage engine | Severity: | S3 (Non-critical) |
Version: | 5.1, 5.5, 5.6 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[2 Sep 2013 12:42]
Alexey Kopytov
[4 Sep 2013 15:15]
Inaam Rana
+1 All these extra push ups around search latch are likely legacy of times when InnoDB used pthread locks. Since plugin 5.1 InnoDB started using atomics based rw-locks and s-lock acquisition should not weigh heavily on performance. I believe all btr_search_latch acquisitions/releases should be pushed to btr0sea.cc.
[3 Oct 2013 13:06]
MySQL Verification Team
Hello Alexey, Thank you for the bug report. Thanks, Umesh
[26 Sep 2014 12:08]
Laurynas Biveinis
revno: 8709 committer: Yasufumi Kinoshita <yasufumi.kinoshita@oracle.com> branch nick: mysql-trunk timestamp: Thu 2014-08-28 13:44:16 +0900 message: Bug#17554489 : UNNECESSARY OVERHEAD FROM PERSISTENT ADAPTIVE HASH INDEX LATCHES If INNODB_RW_LOCKS_USE_ATOMICS is enabled, rw_lock implementation is fast enough. So no need to keep btr_search_latch also when over 10000 times AHI searches per 1 transaction, because just might block the other AHI updates. Approved by Sunny in rb#6257
[14 Oct 2014 23:21]
Daniel Price
Fixed as of the upcoming 5.7.6 release, and here's the changelog entry: Under certain circumstances, adaptive hash index latches ("btr_search_latch") would persist. With "INNODB_RW_LOCKS_USE_ATOMICS" enabled, persistent adpative hash index latches are unnecessary and may block other adaptive hash index updates. Thank you for the bug report.
[14 Oct 2014 23:23]
Daniel Price
Correction to my previous post. This bug is fixed in MySQL 5.7.5.
[6 Aug 2015 9:12]
zhai weixiang
I guess this bug is "really" fixed in MySQL 5.7.8-rc after supporting multi btr_search_latch In function row_search_mvcc , if shortcut search is chosen, the btr_search_latch is always released no matter whether the shortcut search is failed or success. check this the code of 5.7.8 Besides, after this change ,I think the logic bellow in function row_search_mvcc may be redundant if (trx->has_search_latch #ifndef INNODB_RW_LOCKS_USE_ATOMICS && rw_lock_get_writer( btr_get_search_latch(index)) != RW_LOCK_NOT_LOCKED #endif /* !INNODB_RW_LOCKS_USE_ATOMICS */ ) { /* There is an x-latch request on the adaptive hash index: release the s-latch to reduce starvation and wait for BTR_SEA_TIMEOUT rounds before trying to keep it again over calls from MySQL */ trx_search_latch_release_if_reserved(trx); trx->search_latch_timeout = BTR_SEA_TIMEOUT; }