[MDEV-22930] Unnecessary contention on rw_lock_list_mutex in ibuf_dummy_index_create() Created: 2020-06-18 Updated: 2023-08-10 Resolved: 2020-07-08 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB |
| Affects Version/s: | 5.5, 10.0, 10.1, 10.2, 10.3, 10.4, 10.5 |
| Fix Version/s: | 10.5.5 |
| Type: | Bug | Priority: | Major |
| Reporter: | Marko Mäkelä | Assignee: | Eugene Kosov (Inactive) |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | performance | ||
| Attachments: |
2020-06-18 (2).png
2020-06-18 (4).png
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Description |
|
The function ibuf_dummy_index_create() is creating dummy dict_index_t objects for applying buffered changes. The rw_lock_create() call in this function should be totally unnecessary, because there should be no need to access dict_index_t::lock in those dummy objects at all. We should avoid registering the dummy objects in any global lists. When |
| Comments |
| Comment by Vladislav Vaintroub [ 2020-06-18 ] |
|
https://jira.mariadb.org/secure/attachment/52240/2020-06-18%20%282%29.png shows profile snippet of a memory-constrained benchmark (update_index) for which doublewrite was disabled, but change buffer was on. rw_lock_create_func()/rw_lock_free_func() account for more than 2/3 of all mutex contentions, and more than 10% of CPU samples. |
| Comment by Vladislav Vaintroub [ 2020-06-18 ] |
|
Also, CreateTracker::register_latch is very expensive , see https://jira.mariadb.org/secure/attachment/52241/2020-06-18%20%284%29.png This comes from mutex_create(LATCH_ID_ZIP_PAD_MUTEX, &index->zip_pad.mutex); |
| Comment by Marko Mäkelä [ 2020-06-18 ] |
|
I do not think that the dummy index object should really need any synchronization primitives. It should only be used in rec_get_offsets() calculations when applying the buffered changes to the secondary index leaf page. |
