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

Increased congestion on buf_pool.flush_list_mutex

Details

    Description

      The buf_pool.flush_list_mutex became more contended after MDEV-27868 fixed a correctness issue that was caused by the performance fix MDEV-27774. We really should acquire and release buf_pool.flush_list_mutex at most once in mtr_t::commit() and reduce the amount of work performed while holding the mutex.

      Attachments

        Issue Links

          is caused by

          Bug - A problem which impairs or prevents the functions of the product. MDEV-27868 buf_pool.flush_list is in the wrong order

          • Blocker - Blocks development and/or testing work, production could not run.
          • Closed
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-32269 InnoDB after ALTER TABLE…IMPORT TABLESPACE may not be crash safe

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            marko Marko Mäkelä added a comment -

            My first attempt at fixing this could still be improved upon, by refactoring ReleaseModified and its caller so that buf_pool.flush_list_mutex will be acquired and released exactly once, and the correct insert position will be determined only once in case multiple previously clean pages were modified.

            marko Marko Mäkelä added a comment - My first attempt at fixing this could still be improved upon, by refactoring ReleaseModified and its caller so that buf_pool.flush_list_mutex will be acquired and released exactly once, and the correct insert position will be determined only once in case multiple previously clean pages were modified.
            marko Marko Mäkelä added a comment -

            I tested the performance of two variants with regard to garbage (clean blocks in buf_pool.flush_list) encountered while searching for the insert position during mtr_t::commit().

            garbage 20 40 80 160 320 640
            skip 173451.92 216405.04 242115.24 222376.35 232804.73 225682.87
            collect 175827.91 217642.73 244303.73 232586.02 218409.98 225964.44

            The glitch in the 30-second average throughput at 160 and 320 concurrent threads is probably due to checkpoint flushing. The 10-second intervals with maximum throughput from the same run are as follows:

            garbage 20 40 80 160 320 640
            skip 175404.17 228561.55 250756.42 255970.53 246018.71 229484.90
            collect 177563.37 230077.80 252248.08 256343.42 247137.73 228197.05

            The variant with garbage collection seems to perform slightly better.

            marko Marko Mäkelä added a comment - I tested the performance of two variants with regard to garbage (clean blocks in buf_pool.flush_list ) encountered while searching for the insert position during mtr_t::commit() . garbage 20 40 80 160 320 640 skip 173451.92 216405.04 242115.24 222376.35 232804.73 225682.87 collect 175827.91 217642.73 244303.73 232586.02 218409.98 225964.44 The glitch in the 30-second average throughput at 160 and 320 concurrent threads is probably due to checkpoint flushing. The 10-second intervals with maximum throughput from the same run are as follows: garbage 20 40 80 160 320 640 skip 175404.17 228561.55 250756.42 255970.53 246018.71 229484.90 collect 177563.37 230077.80 252248.08 256343.42 247137.73 228197.05 The variant with garbage collection seems to perform slightly better.

            People

              marko Marko Mäkelä
              marko Marko Mäkelä
              Votes:
              0 Vote for this issue
              Watchers:
              1 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.