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

10.1 is 3% slower than 10.0 in OLTP RO

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 10.1
    • Fix Version/s: 10.1.4
    • Component/s: Optimizer
    • Labels:

      Description

      Even though 10.1 has quite a few generic optimizations it still shows slightly worse performance compared to 10.0. This trend can be reproduced quite reliably on different platforms (10.0 -> 10.1):

      1 thread avg TPS: 805.91 -> 780.83 (3.11%)
      1 thread max TPS: 810.60 -> 788.50 (2.73%)
      64 threads avg TPS: 23026.92 -> 22346.58 (2.95%)
      64 threads max TPS: 23245.01 -> 22666.61 (2.49%)
      

      One of the biggest contributors to this slowdown (~2%) seem to be Exec_time_tracker. I get the following numbers if it is commented out (10.0 -> 10.1):

      1 thread avg TPS: 805.91 -> 796.44 (1.18%)
      1 thread max TPS: 810.60 -> 806.29 (0.53%)
      

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            psergey Sergei Petrunia added a comment -

            Following the IRC discussion, I've made a patch that make ANALYZE timing hooks not to be invoked for non-ANALYZE statements.

            However, it made no difference in execution on my system. Sergey Vojtovich, could you please check if the patch fixes the problem?

            Show
            psergey Sergei Petrunia added a comment - Following the IRC discussion, I've made a patch that make ANALYZE timing hooks not to be invoked for non-ANALYZE statements. However, it made no difference in execution on my system. Sergey Vojtovich , could you please check if the patch fixes the problem?
            Hide
            psergey Sergei Petrunia added a comment -

            (Note to self: before this patch is pushed, sort out how it works with UNIONs)

            Show
            psergey Sergei Petrunia added a comment - (Note to self: before this patch is pushed, sort out how it works with UNIONs)
            Hide
            svoj Sergey Vojtovich added a comment -

            The patch seem to be incomplete: ANALYZE_START_TRACKING /ANALYZE_STOP_TRACKING in sql_delete.cc and sql_update.cc were not updated. I'll call those with do_tracking= 1.

            Show
            svoj Sergey Vojtovich added a comment - The patch seem to be incomplete: ANALYZE_START_TRACKING /ANALYZE_STOP_TRACKING in sql_delete.cc and sql_update.cc were not updated. I'll call those with do_tracking= 1.
            Hide
            svoj Sergey Vojtovich added a comment -

            I can see little improvement, almost as good as if it was when I commented it out.

            perf proof (event: cycles):

            ha_index_next() 0.38% -> 0.25%
            my_timer_cycles() - 0.36% -> out of radar
            

            So we freed up 0.49% CPU cycles.

            When tracker functionality is removed from TABLE_IO_WAIT perf says:

            ha_index_next() 0.38% -> 0.18%
            my_timer_cycles() - 0.36% -> out of radar
            

            That is 0.56%.

            Ideally we should have different method with out-of-loop condition check. But that may be complex. Reducing number of conditions from 2 to 1 is trivial and should be worthy:

            #define TABLE_IO_WAIT(TRACKER, PSI, OP, INDEX, FLAGS, PAYLOAD) \
              { \
                if (unlikely(tracker)) \
                { \
                  tracker->start_tracking(); \
                  MYSQL_TABLE_IO_WAIT(PSI, OP, INDEX, FLAGS, PAYLOAD); \
                  tracker->stop_tracking(); \
                } \
                else \
                  MYSQL_TABLE_IO_WAIT(PSI, OP, INDEX, FLAGS, PAYLOAD); \      
              }
            
            Show
            svoj Sergey Vojtovich added a comment - I can see little improvement, almost as good as if it was when I commented it out. perf proof (event: cycles): ha_index_next() 0.38% -> 0.25% my_timer_cycles() - 0.36% -> out of radar So we freed up 0.49% CPU cycles. When tracker functionality is removed from TABLE_IO_WAIT perf says: ha_index_next() 0.38% -> 0.18% my_timer_cycles() - 0.36% -> out of radar That is 0.56%. Ideally we should have different method with out-of-loop condition check. But that may be complex. Reducing number of conditions from 2 to 1 is trivial and should be worthy: #define TABLE_IO_WAIT(TRACKER, PSI, OP, INDEX, FLAGS, PAYLOAD) \ { \ if (unlikely(tracker)) \ { \ tracker->start_tracking(); \ MYSQL_TABLE_IO_WAIT(PSI, OP, INDEX, FLAGS, PAYLOAD); \ tracker->stop_tracking(); \ } \ else \ MYSQL_TABLE_IO_WAIT(PSI, OP, INDEX, FLAGS, PAYLOAD); \ }

              People

              • Assignee:
                psergey Sergei Petrunia
                Reporter:
                svoj Sergey Vojtovich
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: