[MDEV-32068] Some calls to buf_read_ahead_linear() seem to be useless Created: 2023-09-01 Updated: 2023-12-20 Resolved: 2023-12-05 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB |
| Affects Version/s: | 10.1, 10.2, 10.3, 10.4, 10.5, 10.6, 10.7, 10.8, 10.9, 10.10, 10.11, 11.0, 11.1, 11.2 |
| Fix Version/s: | 10.6.17, 10.11.7, 11.0.5, 11.1.4, 11.2.3, 11.3.2 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Marko Mäkelä | Assignee: | Marko Mäkelä |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | performance | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
InnoDB linear read-ahead (which is enabled when innodb_read_ahead_threshold is nonzero) is being invoked in the low-level function buf_page_get_low(). This does not seem useful for page accesses that are likely to be one-time-only, with no anticipation of accessing nearby pages in the near future. We should not attempt to invoke read-ahead on index pages that are not at the leaf level. We should not invoke linear read-ahead in functions that would essentially allocate or free pages, because allocated pages should be reinitialized by buf_page_create(), eliminating the need to read anything from the file system. Likewise, freeing pages should not involve accessing any sibling pages, except for freeing singly-linked lists of BLOB pages. We should not invoke read-ahead in btr_cur_t::pessimistic_search_leaf() or in a pessimistic operation of btr_cur_t::open_leaf(), because pessimistic operations should be preceded by optimistic operations, which should already have invoked read-ahead. By doing all this, we will hopefully improve performance in I/O bound workloads. |
| Comments |
| Comment by Axel Schwenke [ 2023-09-05 ] | ||
|
the overall results show neither improvement nor regression tpcc1.pdf | ||
| Comment by Marko Mäkelä [ 2023-09-05 ] | ||
|
axel, thank you for the results. I’m happy that there is no regression. I see that in the baseline in tpcc1.pdf | ||
| Comment by Matthias Leich [ 2023-09-06 ] | ||
|
| ||
| Comment by Marko Mäkelä [ 2023-11-15 ] | ||
|
This has actually been waiting for me to address the initial review comments that vlad.lesin provided on Septemver 27. Unlike | ||
| Comment by Vladislav Lesin [ 2023-12-04 ] | ||
|
Looks good to me. | ||
| Comment by Marko Mäkelä [ 2023-12-05 ] | ||
|
I tested the impact of removing the read-ahead from trx_undo_get_prev_rec_from_prev_page() and trx_undo_get_first_rec(). This linear read-ahead turned out to improve performance in my extreme benchmark (200MiB of data and 2GiB of undo log pages in a 100MiB buffer pool). So, we will retain the linear read-ahead of undo log pages. |