-
Type:
Bug
-
Resolution: Done
-
Priority:
Critical - P2
-
None
-
Affects Version/s: 2.6.6
-
Component/s: Index Maintenance
-
None
-
ALL
We didn't have such problems with 2.4 so this is more like a regression in 2.6.6.
We have the next indexes:
[
{
"v" : 1,
"name" : "_id_",
"key" : {
"_id" : 1
},
"ns" : "crm_production.sunspot_index_queue_entries"
},
{
"v" : 1,
"key" : {
"record_class_name" : 1,
"record_id" : 1
},
"name" : "record_class_name_1_record_id_1",
"ns" : "crm_production.sunspot_index_queue_entries"
},
{
"v" : 1,
"key" : {
"priority" : -1,
"run_at" : 1,
"lock" : 1,
"record_class_name" : 1
},
"name" : "priority_-1_run_at_1_lock_1_record_class_name_1",
"ns" : "crm_production.sunspot_index_queue_entries"
}
]
And the next query:
'2015-01-07T04:46:25.014-0500 [conn1866] query crm_production.sunspot_index_queue_entries
query: {
$query: { priority: { $gte: -100 }, run_at: { $lte: new Date(1420623970574) }, lock: null, record_class_name: { $in: [ "Site" ] } },
$orderby: { priority: -1, run_at: 1 }
}
planSummary:
IXSCAN { record_class_name: 1.0, record_id: 1.0 },
IXSCAN { record_class_name: 1.0, record_id: 1.0 } cursorid:366254546045 ntoreturn:100 ntoskip:0 nscanned:1421527 nscannedObjects:1421527 keyUpdates:0 numYields:578 locks(micros) r:27845385 nreturned:100 reslen:11362 14434ms'
Previously the query didn't took more than a few ms, now 15 seconds in average.