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

reduce lock_sys.wait_mutex contention by using spinloop construct

Details

    Description

      reduce lock_sys.wait_mutex contention by using spinloop construct

      • wait_mutex plays an important role when the workload involves conflicting transactions.
      • On a heavily contented system with increasing scalability
          quite possible that the majority of the transactions may have to wait
          before acquiring resources.
      • This causes a lot of contention of wait_mutex but most of this
          the contention is short-lived that tend to suggest the use of spin loop
          to avoid giving up compute core that in turn will involve os-scheduler  with additional latency.
      • Idea has shown promising results with performance improving up to 70-100% for write workload.

      Attachments

        Issue Links

          is caused by

          Bug - A problem which impairs or prevents the functions of the product. MDEV-21452 Use condition variables and normal mutexes instead of InnoDB os_event and mutex

          • Major - Major loss of function.
          • Closed
          relates to

          Task - A task that needs to be done. MDEV-16232 Use fewer mini-transactions

          • Major - Major loss of function.
          • Stalled

          Task - A task that needs to be done. MDEV-16406 Refactor the InnoDB record locks

          • Major - Major loss of function.
          • Open

          Activity

            Ascending order - Click to sort in descending order
            View 13 older comments
            krunalbauskar Krunal Bauskar added a comment -

            After folding of the multiple changes related to buf_pool mutex optimization I re-evaluated the said patch.

            1. For uniform (as we observed before) there is no change in performance.
            2. For zipfian (contention case), for ARM there is consistent improvement in performance for higher scalability. For x86, update-non-index 1024 scalability showed some regression. update-index and lower scalability continued to perform well. (Could be due to flushing issue).

            krunalbauskar Krunal Bauskar added a comment - After folding of the multiple changes related to buf_pool mutex optimization I re-evaluated the said patch. 1. For uniform (as we observed before) there is no change in performance. 2. For zipfian (contention case), for ARM there is consistent improvement in performance for higher scalability. For x86, update-non-index 1024 scalability showed some regression. update-index and lower scalability continued to perform well. (Could be due to flushing issue).
            axel Axel Schwenke added a comment -

            MDEV-26779-1.pdf shows no significant performance change. This was however run with uniform RNG and datadir on RAM-disk.

            axel Axel Schwenke added a comment - MDEV-26779-1.pdf shows no significant performance change. This was however run with uniform RNG and datadir on RAM-disk.
            axel Axel Schwenke added a comment -

            MDEV-26779-2.pdf completes the picture with the inlined version. MDEV-26779-3.pdf shows results for the Zipf RNG. In any case it looks like for x86 the non-inlined variant shows the better behavior.

            axel Axel Schwenke added a comment - MDEV-26779-2.pdf completes the picture with the inlined version. MDEV-26779-3.pdf shows results for the Zipf RNG. In any case it looks like for x86 the non-inlined variant shows the better behavior.
            marko Marko Mäkelä added a comment -

            I think that for now, we can apply a simple ARMv8-specific change of initializing lock_sys.wait_mutex with MY_MUTEX_INIT_FAST a.k.a. PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP, similar to how we did to the log_sys mutexes in MDEV-26855.

            I would not change other platforms than ARMv8, because our own tests on AMD64 do not show any significant improvement.

            Spinning is basically a hack to work around contention. The lock_sys.wait_mutex must be split in some way to properly fix this, in a future task.

            marko Marko Mäkelä added a comment - I think that for now, we can apply a simple ARMv8-specific change of initializing lock_sys.wait_mutex with MY_MUTEX_INIT_FAST a.k.a. PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP , similar to how we did to the log_sys mutexes in MDEV-26855 . I would not change other platforms than ARMv8, because our own tests on AMD64 do not show any significant improvement. Spinning is basically a hack to work around contention. The lock_sys.wait_mutex must be split in some way to properly fix this, in a future task.
            marko Marko Mäkelä added a comment -

            I think that before attempting to split lock_sys.wait_mutex, we should implement the following and re-evaluate the situation:

            • MDEV-16232 so that UPDATE and DELETE will avoid setting non-gap locks in the non-contended case
            • MDEV-16406 so that accessing the record locks will hopefully be faster and the critical sections of lock_sys.wait_mutex smaller.
            marko Marko Mäkelä added a comment - I think that before attempting to split lock_sys.wait_mutex , we should implement the following and re-evaluate the situation: MDEV-16232 so that UPDATE and DELETE will avoid setting non-gap locks in the non-contended case MDEV-16406 so that accessing the record locks will hopefully be faster and the critical sections of lock_sys.wait_mutex smaller.

            People

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