Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-14525

Perf regression in 2.6.2 caused by not caching plans that tie during plan ranking

    • Type: Icon: Bug Bug
    • Resolution: Duplicate
    • Priority: Icon: Critical - P2 Critical - P2
    • None
    • Affects Version/s: 2.6.3
    • Component/s: Querying
    • ALL
    • Hide
      var tests=[]
      load ('./mongo-perf/util/utils.js')
      
      tests.push( { name: "Queries.TwoInts",
        pre: function( collection ) {
               collection.drop();
               for ( var i = 0; i < 1000; i++ ) {
                 collection.insert( { x: i, y: 2*i } );
               }
               collection.ensureIndex({x: 1});
               collection.ensureIndex({y: 1});
             },
        ops : [
          { op: "find",
            query: { x: { "#SEQ_INT": { seq_id: 0, start: 0, step: 1, mod: 1000 } },
                     y: { "#SEQ_INT": { seq_id: 1, start: 0, step: 2, mod: 2000 } } }
          }
              ]
      } );
      
      runTests([1, 2, 4, 8, 16, 32], 1,'bisect', 'localhost', '27017');
      
      Show
      var tests=[] load ( './mongo-perf/util/utils.js' ) tests.push( { name: "Queries.TwoInts" , pre: function( collection ) { collection.drop(); for ( var i = 0; i < 1000; i++ ) { collection.insert( { x: i, y: 2*i } ); } collection.ensureIndex({x: 1}); collection.ensureIndex({y: 1}); }, ops : [ { op: "find" , query: { x: { "#SEQ_INT" : { seq_id: 0, start: 0, step: 1, mod: 1000 } }, y: { "#SEQ_INT" : { seq_id: 1, start: 0, step: 2, mod: 2000 } } } } ] } ); runTests([1, 2, 4, 8, 16, 32], 1, 'bisect' , 'localhost' , '27017' );

      For scenarios in which plans repeatedly tie, SERVER-13675 introduces a performance regression. Ties can actually be quite common for some indexing schemes. For example, you might have indices {a: 1, b: 1} and {a: 1, c: 1} to support two different query patterns. When you query with a predicate over 'a' and without predicates over either 'b' or 'c', however, the two indices will always tie. Not caching one of the two tied plans means that we do extra work by going through the MultiPlanRunner path for every query of this shape.

      Original Description

      Problem:
      Using mongo-perf, the Queries.TwoInts regresses in throughput from 2.6.1 to 2.6.2
      Good 2.6.1

      @@@START@@@
      Queries.TwoInts
              1       15183.6
              2       31095.600000000002
              4       49195.200000000004
              8       84476.8
              16      105745.2
              32      110057.8
      @@@END@@@
      {
              "[object Object]" : {
                      "1" : {
                              "ops_per_sec" : 15183.6
                      },
                      "2" : {
                              "ops_per_sec" : 31095.600000000002
                      },
                      "4" : {
                              "ops_per_sec" : 49195.200000000004
                      },
                      "8" : {
                              "ops_per_sec" : 84476.8
                      },
                      "16" : {
                              "ops_per_sec" : 105745.2
                      },
                      "32" : {
                              "ops_per_sec" : 110057.8
                      }
              }
      }
      

      Bad Githash: 213700b3af4d53ce7e808dce2c638d98fc4f91db

      @@@START@@@
      Queries.TwoInts
              1       9583.400000000001
              2       19006.199999999997
              4       33435
              8       53750.399999999994
              16      65717.4
              32      67228.8
      @@@END@@@
      {
              "[object Object]" : {
                      "1" : {
                              "ops_per_sec" : 9583.400000000001
                      },
                      "2" : {
                              "ops_per_sec" : 19006.199999999997
                      },
                      "4" : {
                              "ops_per_sec" : 33435
                      },
                      "8" : {
                              "ops_per_sec" : 53750.399999999994
                      },
                      "16" : {
                              "ops_per_sec" : 65717.4
                      },
                      "32" : {
                              "ops_per_sec" : 67228.8
                      }
              }
      }
      

            Assignee:
            david.storch@mongodb.com David Storch
            Reporter:
            alvin Alvin Richards (Inactive)
            Votes:
            12 Vote for this issue
            Watchers:
            24 Start watching this issue

              Created:
              Updated:
              Resolved: