Details
-
Bug
-
Resolution: Done
-
Critical - P2
-
None
-
2.6.6
-
None
-
ALL
Description
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.