[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: PDF File tpcc1.pdf    
Issue Links:
Blocks
blocks MDEV-32067 InnoDB linear read ahead had better b... Open

 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 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.

Comment by Matthias Leich [ 2023-09-06 ]

origin/bb-10.6-MDEV-32068 a26c51a190030443063362eb3f21c510fcb3c734 2023-09-05T16:30:53+03:00
performed well during RQG testing. No unknown bugs hit.

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 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.

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.

Generated at Thu Feb 08 10:28:35 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.