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

Table_open_cache scalability issues

        Details

        • Type: Bug
        • Status: Closed
        • Priority: Major
        • Resolution: Incomplete
        • Affects Version/s: 10.0.15
        • Fix Version/s: 10.0.16
        • Component/s: OTHER
        • Labels:
          None
        • Environment:
          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.

            Gliffy Diagrams

              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
                  Hide
                  Permalink
                  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?

                  Show
                  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?
                  Hide
                  Permalink
                  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.

                  Show
                  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

                    • Assignee:
                      svoj Sergey Vojtovich
                      Reporter:
                      tanj Guillaume Lefranc
                    • Votes:
                      2 Vote for this issue
                      Watchers:
                      5 Start watching this issue

                      Dates

                      • Created:
                        Updated:
                        Resolved: