[SERVER-6728] B-tree scans are significantly slower in 2.2 vs. 2.0 Created: 07/Aug/12  Updated: 15/Aug/12  Resolved: 07/Aug/12

Status: Closed
Project: Core Server
Component/s: Index Maintenance
Affects Version/s: 2.2.0-rc0
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Jeremy Mikola Assignee: Andy Schwerin
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
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


Attachments: File reads.js    
Issue Links:
Duplicate
duplicates SERVER-6572 Performance issue Closed
Related
Operating System: ALL
Participants:

 Description   

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



 Comments   
Comment by Eliot Horowitz (Inactive) [ 07/Aug/12 ]

Same issue as SERVER-6572

Generated at Thu Feb 08 03:12:32 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.