Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.1(EOL), (13)
10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL), 10.11, 11.0(EOL), 11.1(EOL), 11.2(EOL)
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.
Attachments
Issue Links
- blocks
-
-
- Confirmed
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Link | This issue blocks MDEV-32067 [ MDEV-32067 ] |
| Attachment | tpcc1.pdf [ 71853 ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
axel, thank you for the results. I’m happy that there is no regression. I see that in the baseline in tpcc1.pdf
there are two dips in the throughput, which are missing for the change under test. This could be luck or a sign of actual improvement, now that some B-tree operations are the only ones that can trigger linear read-ahead.
| Assignee | Marko Mäkelä [ marko ] | Vladislav Lesin [ vlad.lesin ] |
| Status | In Progress [ 3 ] | In Review [ 10002 ] |
origin/bb-10.6-MDEV-32068 a26c51a190030443063362eb3f21c510fcb3c734 2023-09-05T16:30:53+03:00
|
performed well during RQG testing. No unknown bugs hit.
|
| Priority | Major [ 3 ] | Critical [ 2 ] |
| Assignee | Vladislav Lesin [ vlad.lesin ] | Marko Mäkelä [ marko ] |
This has actually been waiting for me to address the initial review comments that vlad.lesin provided on Septemver 27. Unlike MDEV-30531, which kept me busy for quite some time, this is not likely to yield significant performance gains, but I think that it still is worthwhile as a preparation for MDEV-32067.
| Status | In Review [ 10002 ] | Stalled [ 10000 ] |
| Status | Stalled [ 10000 ] | In Progress [ 3 ] |
| Assignee | Marko Mäkelä [ marko ] | Vladislav Lesin [ vlad.lesin ] |
| Status | In Progress [ 3 ] | In Review [ 10002 ] |
| Fix Version/s | 10.10 [ 27530 ] |
| Status | In Review [ 10002 ] | Stalled [ 10000 ] |
| Assignee | Vladislav Lesin [ vlad.lesin ] | Marko Mäkelä [ marko ] |
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.
| issue.field.resolutiondate | 2023-12-05 11:33:53.0 | 2023-12-05 11:33:53.142 |
| Fix Version/s | 10.6.17 [ 29518 ] | |
| Fix Version/s | 10.11.7 [ 29519 ] | |
| Fix Version/s | 11.0.5 [ 29520 ] | |
| Fix Version/s | 11.1.4 [ 29024 ] | |
| Fix Version/s | 11.2.3 [ 29521 ] | |
| Fix Version/s | 11.3.2 [ 29522 ] | |
| Fix Version/s | 10.6 [ 24028 ] | |
| Fix Version/s | 10.11 [ 27614 ] | |
| Fix Version/s | 11.0 [ 28320 ] | |
| Fix Version/s | 11.1 [ 28549 ] | |
| Fix Version/s | 11.2 [ 28603 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | Stalled [ 10000 ] | Closed [ 6 ] |
the overall results show neither improvement nor regression tpcc1.pdf