It goes straight to the right shard and hits the index without any problem. I'm suspecting locks as the problem here, is there anything else I can look at?
In the explain output you included, it doesn't show as a slow query with many yields .
Could you try another query hasn't perhaps already run in the system and is the not yet in the active memory set. Just to get a better sense on a slow query.
Also what is shard setup? sh.status()
And do you have mms installed? http://mms.10gen.com It helps to have a better understanding of what all the various pieces of mongo are doing.
> It goes straight to the right shard and hits the index without any > problem. I'm suspecting locks as the problem here, is there anything else I > can look at?
> Thanks,
> Josh.
> On Friday, October 12, 2012 1:37:18 PM UTC+1, Gianfranco wrote:
>> Hi Josh,
>> Are these queries using indexes? >> If you run explain() at the end of the find() for example you see if and >> which index is being used.
>> Database locking is 2.2
>> Collecting level locking is planned but without a definitive schedule yet >> as it impacts a large part of the server code. >> https://jira.mongodb.org/browse/SERVER-1240
>> Gianfranco
>> On Friday, October 12, 2012 11:27:10 AM UTC+1, josh wrote:
>>> Hi,
>>> I notice every now and then, since upgrading to 2.2 I see some slow >>> running quries, some of them are probably due to yields:
This one took over a second but I think it's due to the fact that it wasn't in memory: db.RAT.find({ component_id: "4560352977" }).explain() { "clusteredType" : "ParallelSort", "shards" : { "data1/mongo1:27021,mongo2:27021" : [ { "cursor" : "BtreeCursor component_id_1", "isMultiKey" : false, "n" : 0, "nscannedObjects" : 0, "nscanned" : 0, "nscannedObjectsAllPlans" : 0, "nscannedAllPlans" : 0, "scanAndOrder" : false, "indexOnly" : false, "nYields" : 0, "nChunkSkips" : 0, "millis" : 0, "indexBounds" : { "component_id" : [ [ "4560352977", "4560352977" ] ] }, "server" : "mongo1:27021" } ] }, "cursor" : "BtreeCursor component_id_1", "n" : 0, "nChunkSkips" : 0, "nYields" : 0, "nscanned" : 0, "nscannedAllPlans" : 0, "nscannedObjects" : 0, "nscannedObjectsAllPlans" : 0, "millisShardTotal" : 0, "millisShardAvg" : 0, "numQueries" : 1, "numShards" : 1, "indexBounds" : { "component_id" : [ [ "4560352977", "4560352977" ] ] }, "millis" : 1397
}
The slow running queries problem is an intermittent one so I can't run .explain() as I never know when it's going to happen, what I can say is that it's usually crippling when it does happend...
On Friday, October 12, 2012 4:03:25 PM UTC+1, Gianfranco wrote:
> In the explain output you included, it doesn't show as a slow query with > many yields .
> Could you try another query hasn't perhaps already run in the system and > is the not yet in the active memory set. > Just to get a better sense on a slow query.
> Also what is shard setup? sh.status()
> And do you have mms installed? > http://mms.10gen.com > It helps to have a better understanding of what all the various pieces of > mongo are doing.
> Gianfranco
> On Friday, October 12, 2012 3:43:29 PM UTC+1, josh wrote:
>> It goes straight to the right shard and hits the index without any >> problem. I'm suspecting locks as the problem here, is there anything else I >> can look at?
>> Thanks,
>> Josh.
>> On Friday, October 12, 2012 1:37:18 PM UTC+1, Gianfranco wrote:
>>> Hi Josh,
>>> Are these queries using indexes? >>> If you run explain() at the end of the find() for example you see if and >>> which index is being used.
>>> Database locking is 2.2
>>> Collecting level locking is planned but without a definitive schedule >>> yet as it impacts a large part of the server code. >>> https://jira.mongodb.org/browse/SERVER-1240
>>> Gianfranco
>>> On Friday, October 12, 2012 11:27:10 AM UTC+1, josh wrote:
>>>> Hi,
>>>> I notice every now and then, since upgrading to 2.2 I see some slow >>>> running quries, some of them are probably due to yields:
sitemaker.CT chunks: data3 370 data1 370 data4 370 data2 377 too many chunks to print, use verbose if you want to force print sitemaker.CTTHIN chunks: data4 159 data2 160 data3 159 data1 162 too many chunks to print, use verbose if you want to force print sitemaker.RAT chunks: data3 211 data1 211 data4 211 data2 213 too many chunks to print, use verbose if you want to force print sitemaker.html chunks: data4 29 data2 29 data1 32 data3 29 too many chunks to print, use verbose if you want to force print
> The slow running queries problem is an intermittent one so I can't run > .explain() as I never know when it's going to happen, what I can say is > that it's usually crippling when it does happend...
> I'll install mms on Monday.
> Thanks,
> Josh.
> On Friday, October 12, 2012 4:03:25 PM UTC+1, Gianfranco wrote:
>> In the explain output you included, it doesn't show as a slow query with >> many yields .
>> Could you try another query hasn't perhaps already run in the system and >> is the not yet in the active memory set. >> Just to get a better sense on a slow query.
>> Also what is shard setup? sh.status()
>> And do you have mms installed? >> http://mms.10gen.com >> It helps to have a better understanding of what all the various pieces of >> mongo are doing.
>> Gianfranco
>> On Friday, October 12, 2012 3:43:29 PM UTC+1, josh wrote:
>>> It goes straight to the right shard and hits the index without any >>> problem. I'm suspecting locks as the problem here, is there anything else I >>> can look at?
>>> Thanks,
>>> Josh.
>>> On Friday, October 12, 2012 1:37:18 PM UTC+1, Gianfranco wrote:
>>>> Hi Josh,
>>>> Are these queries using indexes? >>>> If you run explain() at the end of the find() for example you see if >>>> and which index is being used.
>>>> Database locking is 2.2
>>>> Collecting level locking is planned but without a definitive schedule >>>> yet as it impacts a large part of the server code. >>>> https://jira.mongodb.org/browse/SERVER-1240
>>>> Gianfranco
>>>> On Friday, October 12, 2012 11:27:10 AM UTC+1, josh wrote:
>>>>> Hi,
>>>>> I notice every now and then, since upgrading to 2.2 I see some slow >>>>> running quries, some of them are probably due to yields:
>> The slow running queries problem is an intermittent one so I can't run >> .explain() as I never know when it's going to happen, what I can say is >> that it's usually crippling when it does happend...
>> I'll install mms on Monday.
>> Thanks,
>> Josh.
>> On Friday, October 12, 2012 4:03:25 PM UTC+1, Gianfranco wrote:
>>> In the explain output you included, it doesn't show as a slow query with >>> many yields .
>>> Could you try another query hasn't perhaps already run in the system and >>> is the not yet in the active memory set. >>> Just to get a better sense on a slow query.
>>> Also what is shard setup? sh.status()
>>> And do you have mms installed? >>> http://mms.10gen.com >>> It helps to have a better understanding of what all the various pieces >>> of mongo are doing.
>>> Gianfranco
>>> On Friday, October 12, 2012 3:43:29 PM UTC+1, josh wrote:
>>>> It goes straight to the right shard and hits the index without any >>>> problem. I'm suspecting locks as the problem here, is there anything else I >>>> can look at?
>>>> Thanks,
>>>> Josh.
>>>> On Friday, October 12, 2012 1:37:18 PM UTC+1, Gianfranco wrote:
>>>>> Hi Josh,
>>>>> Are these queries using indexes? >>>>> If you run explain() at the end of the find() for example you see if >>>>> and which index is being used.
>>>>> Database locking is 2.2
>>>>> Collecting level locking is planned but without a definitive schedule >>>>> yet as it impacts a large part of the server code. >>>>> https://jira.mongodb.org/browse/SERVER-1240
>>>>> Gianfranco
>>>>> On Friday, October 12, 2012 11:27:10 AM UTC+1, josh wrote:
>>>>>> Hi,
>>>>>> I notice every now and then, since upgrading to 2.2 I see some slow >>>>>> running quries, some of them are probably due to yields:
>>> The slow running queries problem is an intermittent one so I can't run >>> .explain() as I never know when it's going to happen, what I can say is >>> that it's usually crippling when it does happend...
>>> I'll install mms on Monday.
>>> Thanks,
>>> Josh.
>>> On Friday, October 12, 2012 4:03:25 PM UTC+1, Gianfranco wrote:
>>>> In the explain output you included, it doesn't show as a slow query >>>> with many yields .
>>>> Could you try another query hasn't perhaps already run in the system >>>> and is the not yet in the active memory set. >>>> Just to get a better sense on a slow query.
>>>> Also what is shard setup? sh.status()
>>>> And do you have mms installed? >>>> http://mms.10gen.com >>>> It helps to have a better understanding of what all the various pieces >>>> of mongo are doing.
>>>> Gianfranco
>>>> On Friday, October 12, 2012 3:43:29 PM UTC+1, josh wrote:
>>>>> It goes straight to the right shard and hits the index without any >>>>> problem. I'm suspecting locks as the problem here, is there anything else I >>>>> can look at?
>>>>> Thanks,
>>>>> Josh.
>>>>> On Friday, October 12, 2012 1:37:18 PM UTC+1, Gianfranco wrote:
>>>>>> Hi Josh,
>>>>>> Are these queries using indexes? >>>>>> If you run explain() at the end of the find() for example you see if >>>>>> and which index is being used.
>>>>>> Database locking is 2.2
>>>>>> Collecting level locking is planned but without a definitive schedule >>>>>> yet as it impacts a large part of the server code. >>>>>> https://jira.mongodb.org/browse/SERVER-1240
>>>>>> Gianfranco
>>>>>> On Friday, October 12, 2012 11:27:10 AM UTC+1, josh wrote:
>>>> The slow running queries problem is an intermittent one so I can't run >>>> .explain() as I never know when it's going to happen, what I can say is >>>> that it's usually crippling when it does happend...
>>>> I'll install mms on Monday.
>>>> Thanks,
>>>> Josh.
>>>> On Friday, October 12, 2012 4:03:25 PM UTC+1, Gianfranco wrote:
>>>>> In the explain output you included, it doesn't show as a slow query >>>>> with many yields .
>>>>> Could you try another query hasn't perhaps already run in the system >>>>> and is the not yet in the active memory set. >>>>> Just to get a better sense on a slow query.
>>>>> Also what is shard setup? sh.status()
>>>>> And do you have mms installed? >>>>> http://mms.10gen.com >>>>> It helps to have a better understanding of what all the various pieces >>>>> of mongo are doing.
>>>>> Gianfranco
>>>>> On Friday, October 12, 2012 3:43:29 PM UTC+1, josh wrote:
>>>>>> It goes straight to the right shard and hits the index without any >>>>>> problem. I'm suspecting locks as the problem here, is there anything else I >>>>>> can look at?
>>>>>> Thanks,
>>>>>> Josh.
>>>>>> On Friday, October 12, 2012 1:37:18 PM UTC+1, Gianfranco wrote:
>>>>>>> Hi Josh,
>>>>>>> Are these queries using indexes? >>>>>>> If you run explain() at
