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

B-tree scans are significantly slower in 2.2 vs. 2.0

    • Type: Icon: Bug Bug
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: 2.2.0-rc0
    • Component/s: Index Maintenance
    • Labels:
      None
    • Environment:
      Linux 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6 14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
    • ALL

      While responding to this thread, I realized that b-tree scans were happening much slower in 2.2.0-rc0 than they were in the stable 2.0 branch.

      I'm attaching the test script, which is also available at https://gist.github.com/3184175.

      Here is a comparison of 2.0 and 2.2.0-rc1-pre-:

      $ mongo reads.js
      MongoDB shell version: 2.0.6
      connecting to: test
      
      ----
      One batch of 100 queries in the 75-100k range
      ----
      
      batch 1 nscanned: 1269469
      total time: 3.379
      btree.accesses: 0
      btree.hits: 0
      btree.misses: 0
      btree.resets: 0
      btree.missRatio: 0
      
      ----
      Four batches of 25 queries in the 0-25, 25-50, 50-75, and 75-100k ranges
      ----
      
      batch 1 nscanned: 324675
      batch 2 nscanned: 974675
      batch 3 nscanned: 975800
      batch 4 nscanned: 325819
      total time: 6.688
      btree.accesses: 0
      btree.hits: 0
      btree.misses: 0
      btree.resets: 0
      btree.missRatio: 0
      
      
      
      $ mongo reads.js
      MongoDB shell version: 2.2.0-rc1-pre-
      connecting to: test
      
      ----
      One batch of 100 queries in the 75-100k range
      ----
      
      batch 1 nscanned: 1269469
      total time: 5.956
      btree.accesses: 0
      btree.hits: 0
      btree.misses: 0
      btree.resets: 0
      btree.missRatio: 0
      
      ----
      Four batches of 25 queries in the 0-25, 25-50, 50-75, and 75-100k ranges
      ----
      
      batch 1 nscanned: 324675
      batch 2 nscanned: 974675
      batch 3 nscanned: 975800
      batch 4 nscanned: 325819
      total time: 11.918
      btree.accesses: 0
      btree.hits: 0
      btree.misses: 0
      btree.resets: 0
      btree.missRatio: 0
      

      Andy initially suspected this might be related to SERVER-6572, and suggested that I re-run this benchmark after setting Record::MemoryTrackingEnabled to false in src/mongo/db/record.cpp. That marginally increased performance, but the results are still much slower than 2.0. Here are those results are:

      $ mongo reads.js 
      MongoDB shell version: 2.2.0-rc1-pre- with memory tracking disabled
      connecting to: test
      batch 1 nscanned: 1269469
      total time: 5.246
      btree.accesses: 0
      btree.hits: 0
      btree.misses: 0
      btree.resets: 0
      btree.missRatio: 0
      batch 1 nscanned: 324675
      batch 2 nscanned: 974675
      batch 3 nscanned: 975800
      batch 4 nscanned: 325819
      total time: 10.574
      btree.accesses: 0
      btree.hits: 0
      btree.misses: 0
      btree.resets: 0
      btree.missRatio: 0
      
      $ mongo reads.js 
      MongoDB shell version: 2.2.0-rc1-pre-
      connecting to: test
      batch 1 nscanned: 1269469
      total time: 5.756
      btree.accesses: 0
      btree.hits: 0
      btree.misses: 0
      btree.resets: 0
      btree.missRatio: 0
      batch 1 nscanned: 324675
      batch 2 nscanned: 974675
      batch 3 nscanned: 975800
      batch 4 nscanned: 325819
      total time: 11.91
      btree.accesses: 0
      btree.hits: 0
      btree.misses: 0
      btree.resets: 0
      btree.missRatio: 0
      

            Assignee:
            schwerin@mongodb.com Andy Schwerin
            Reporter:
            jmikola@mongodb.com Jeremy Mikola
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: