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

Unnecessary contention on rw_lock_list_mutex in ibuf_dummy_index_create()

Details

    Description

      The function ibuf_dummy_index_create() is creating dummy dict_index_t objects for applying buffered changes. The rw_lock_create() call in this function should be totally unnecessary, because there should be no need to access dict_index_t::lock in those dummy objects at all. We should avoid registering the dummy objects in any global lists.

      When MDEV-11634 implements a more compact change buffer format, that entire code should be removed, or only kept for the purpose of upgrading.

      Attachments

        Issue Links

          relates to

          Task - A task that needs to be done. MDEV-11634 Improve the InnoDB change buffer

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-31886 Server fails to shut down storage engine plugins when thread_stack is set to the smallest negative value

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Confirmed

          Activity

            Ascending order - Click to sort in descending order
            wlad Vladislav Vaintroub added a comment - - edited

            https://jira.mariadb.org/secure/attachment/52240/2020-06-18%20%282%29.png shows profile snippet of a memory-constrained benchmark (update_index) for which doublewrite was disabled, but change buffer was on.

            rw_lock_create_func()/rw_lock_free_func() account for more than 2/3 of all mutex contentions, and more than 10% of CPU samples.

            wlad Vladislav Vaintroub added a comment - - edited https://jira.mariadb.org/secure/attachment/52240/2020-06-18%20%282%29.png shows profile snippet of a memory-constrained benchmark (update_index) for which doublewrite was disabled, but change buffer was on. rw_lock_create_func()/rw_lock_free_func() account for more than 2/3 of all mutex contentions, and more than 10% of CPU samples.
            wlad Vladislav Vaintroub added a comment - - edited

            Also, CreateTracker::register_latch is very expensive , see https://jira.mariadb.org/secure/attachment/52241/2020-06-18%20%284%29.png

            This comes from mutex_create(LATCH_ID_ZIP_PAD_MUTEX, &index->zip_pad.mutex);

            wlad Vladislav Vaintroub added a comment - - edited Also, CreateTracker::register_latch is very expensive , see https://jira.mariadb.org/secure/attachment/52241/2020-06-18%20%284%29.png This comes from mutex_create(LATCH_ID_ZIP_PAD_MUTEX, &index->zip_pad.mutex);
            marko Marko Mäkelä added a comment -

            I do not think that the dummy index object should really need any synchronization primitives. It should only be used in rec_get_offsets() calculations when applying the buffered changes to the secondary index leaf page.

            marko Marko Mäkelä added a comment - I do not think that the dummy index object should really need any synchronization primitives. It should only be used in rec_get_offsets() calculations when applying the buffered changes to the secondary index leaf page.

            People

              kevg Eugene Kosov (Inactive)
              marko Marko Mäkelä
              Votes:
              1 Vote for this issue
              Watchers:
              2 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.