Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-32068

Some calls to buf_read_ahead_linear() seem to be useless

Details

    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

          Activity

            axel Axel Schwenke added a comment -

            the overall results show neither improvement nor regression tpcc1.pdf

            axel Axel Schwenke added a comment - the overall results show neither improvement nor regression tpcc1.pdf

            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.

            marko Marko Mäkelä added a comment - 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.

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

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

            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.

            marko Marko Mäkelä added a comment - 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 .

            Looks good to me.

            vlad.lesin Vladislav Lesin added a comment - Looks good to me.

            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.

            marko Marko Mäkelä added a comment - 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.

            People

              marko Marko Mäkelä
              marko Marko Mäkelä
              Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.