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

Table_open_cache scalability issues

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Incomplete
    • 10.0.15
    • 10.0.16
    • OTHER
    • None
    • Debian wheezy x86_64

    Description

      Hello,

      in spite of recent effors, table_open_cache still seems to be hit by negative scalability. I ran the following benchmark tests:

      • SET GLOBAL table_open_cache = 64
      • Create 10,000 MyISAM Tables with a single integer
      • Access all tables in a loop
      • SET GLOBAL table_open_cache = 4000
      • Access all tables in a loop

      Results are the following:
      Table creation: 4s (sync_frm=0)
      SELECT, Table_open_cache=64: 1.696519199s
      SELECT, Table_open_cache=4000: 5.946816624s

      The results are quite consistent and performance seems to decrease linearly.

      My biggest concern is that MariaDB 5.5.40 is 2x faster with this test:

      Selecting from tables with default cache (64)
      Time: 1.536537015s
      Selecting from tables with extended cache (4000)
      Time: 2.798534456s

      The only good news is that MySQL 5.6 seems to do worse with this test, with 6s and 9s respectively.

      Attachments

        Issue Links

          relates to

          Task - A task that needs to be done. MDEV-5388 Reduce usage of LOCK_open: unused_tables

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-5864 Reduce usage of LOCK_open: TABLE_SHARE::tdc.free_tables

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            svoj Sergey Vojtovich added a comment -

            We did improve scalability issues of concurrent connections accessing table cache. That is increased throughput of systems with high connection counts.

            In all your examples (even 5.5.40) table_open_cache=64 shows better performance. So what's the point of high table_open_cache for such load?

            svoj Sergey Vojtovich added a comment - We did improve scalability issues of concurrent connections accessing table cache. That is increased throughput of systems with high connection counts. In all your examples (even 5.5.40) table_open_cache=64 shows better performance. So what's the point of high table_open_cache for such load?
            svoj Sergey Vojtovich added a comment -

            To fix this bug properly we need to understand reasons for setting high table_open_cache for such load. Closing this bug as incomplete for now. Feel free to reopen it with additional information.

            svoj Sergey Vojtovich added a comment - To fix this bug properly we need to understand reasons for setting high table_open_cache for such load. Closing this bug as incomplete for now. Feel free to reopen it with additional information.

            People

              svoj Sergey Vojtovich
              tanj Guillaume Lefranc
              Votes:
              2 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.