Received: by 10.59.6.72 with SMTP id cs8mr8355376ved.27.1352854157580;
Tue, 13 Nov 2012 16:49:17 -0800 (PST)
X-BeenThere: mongodb-user@googlegroups.com
Received: by 10.52.34.13 with SMTP id v13ls67667vdi.3.gmail; Tue, 13 Nov 2012
16:49:04 -0800 (PST)
Received: by 10.52.19.201 with SMTP id h9mr10413vde.0.1352854144496;
Tue, 13 Nov 2012 16:49:04 -0800 (PST)
Date: Tue, 13 Nov 2012 16:49:04 -0800 (PST)
From: Rob Moore <robert.allanb...@gmail.com>
To: mongodb-user@googlegroups.com
Message-Id: <33d8a23e-7a00-46cc-bfc9-7acec51dcc97@googlegroups.com>
In-Reply-To: <071663e6-bff3-4993-8c4a-342ac17b64fd@googlegroups.com>
References: <bc0a2d99-04c2-4f4d-b0da-6d83de9559c0@googlegroups.com>
<CA+C=T4C80RRSQBdFhOogjG0K3yRnYeuz+2j_DrEG5gcqGdxr=g@mail.gmail.com>
<db8bf880-7388-495f-9451-d0976434a1bb@googlegroups.com>
<CA+C=T4C=RGYAvUG1SkvahjBLMuGQ4oVnVz79KJ4W0pTojTDifg@mail.gmail.com>
<4FF599BF.9030303@gmail.com>
<CA+C=T4Da3UO_XJ+ZCM3FdDZzjb45zrPstshhXNrB91gxPNrhvQ@mail.gmail.com>
<1020b565-5bbb-496d-aa43-26181b813fe3@googlegroups.com>
<08d8aa1d-7ce3-43cb-95cb-5f2796addad3@googlegroups.com>
<3b7289ce-9b30-4e88-bfed-ad3c8a935e6a@googlegroups.com>
<071663e6-bff3-4993-8c4a-342ac17b64fd@googlegroups.com>
Subject: Re: [mongodb-user] How to keep it all in RAM ?
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_300_7596612.1352854144070"
------=_Part_300_7596612.1352854144070
Content-Type: multipart/alternative;
boundary="----=_Part_301_1644708.1352854144070"
------=_Part_301_1644708.1352854144070
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Sorry - Not sure how I missed the database name. =20
Did you get a chance to look for long running commands using the profiler?
For the queries: Are you expecting to scan a range? There are a lot of=20
getmore commands so either the batch size is being set small or there is a=
=20
query scanning large parts of the collection.
For the updates: What write concern are you using?
Rob.
On Friday, November 9, 2012 6:08:23 AM UTC-5, J=C3=A9r=C3=A9my Lecour wrote=
:
>
>
>
> Le vendredi 9 novembre 2012 02:37:52 UTC+1, Rob Moore a =C3=A9crit :
>
> Hi Rob,
>
> Many thanks for your answer.
>
> How is the "hh" collection used. That is the one that is locked based on=
=20
>> the mongostat. =20
>>
>
> "hh" is the database, "searches" is the mainly used collection.
>
> The typical use is described in my original message
>
>
> My "searches" collection is used like this :
>>>
>>> * <20K records, quite big, with deep BSON structure
>>> * read/writes are almost 95% of the time using the primary index (which=
=20
>>> is not an ObjectID but an integer for an historic reason)
>>> * a lot of updates are touching the same record at the same time, but o=
n=20
>>> different parts of it
>>>
>>
> =20
>
>> Have you tried turning on the built in profiler to see what the slow=20
>> operations are? http://www.mongodb.org/display/DOCS/Database+Profiler
>
>
> Not yet, I'll do that.
>
> =20
>
>> Also on indexes:
>> "_id_" : 228928,
>> "created_at_-1" : 212576,
>> "created_at_1" : 228928,
>> "updated_at_-1" : 212576,
>> "updated_at_1" : 228928,
>> "recent_search_index" : 376096
>>
>> You don't need both the "created_at_-1" and "created_at_1". MongoDB=20
>> knows how to reverse the direction of the index. Similar argument for=
=20
>> updated_at.
>>
>
> Thanks, I've changed that, but I doubt it's the cause of my problem.
>
> --
> J=C3=A9r=C3=A9my
>
------=_Part_301_1644708.1352854144070
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<br>Sorry - Not sure how I missed the database name. <br><br>Did you =
get a chance to look for long running commands using the profiler?<br><br>F=
or the queries: Are you expecting to scan a range? There are a lot of=
getmore commands so either the batch size is being set small or there is a=
query scanning large parts of the collection.<br><br>For the updates: What=
write concern are you using?<br><br>Rob.<br><br><br>On Friday, November 9,=
2012 6:08:23 AM UTC-5, J=C3=A9r=C3=A9my Lecour wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div><br><br>Le vendredi 9 novembre 2012 02:37:52 U=
TC+1, Rob Moore a =C3=A9crit :</div><div><br></div><div>Hi Rob,<div><b=
r></div><div>Many thanks for your answer.</div></div><div><br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex">How is the "hh" collection used. That is t=
he one that is locked based on the mongostat. <br></blockquote><div><=
br></div><div>"hh" is the database, "searches" is the mainly used collectio=
n.</div><div><br></div><div>The typical use is described in my original mes=
sage</div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg=
b(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div>My "searches" collection is used like this :</div><div><br></div><div>=
* <20K records, quite big, with deep BSON structure</div><div>* read/wri=
tes are almost 95% of the time using the primary index (which is not an Obj=
ectID but an integer for an historic reason)</div><div>* a lot of updates a=
re touching the same record at the same time, but on different parts of it<=
/div></blockquote></blockquote><div><br></div><div> </div><blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex">Have you tried turning on the built in profiler=
to see what the slow operations are? <a href=3D"http://www.mongodb.o=
rg/display/DOCS/Database+Profiler" target=3D"_blank">http://www.mongodb.org=
/<wbr>display/DOCS/Database+Profiler</a></blockquote><div><br></div><div>No=
t yet, I'll do that.</div><div><br></div><div> </div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">Also on indexes:<br><div> =
"_id_" : 228928,</div><div>  =
; "created_at_-1" : 212576,</div><div>&n=
bsp; "created_at_1" : 2289=
28,</div><div> "upda=
ted_at_-1" : 212576,</div><div> &n=
bsp; "updated_at_1" : 228928,</div><div> =
"recent_search_index" : 376096<br><br>You don't=
need both the "created_at_-1" and "created_at_1". MongoDB knows how=
to reverse the direction of the index. Similar argument for updated_=
at.<br></div></blockquote><div><br></div><div>Thanks, I've changed that, bu=
t I doubt it's the cause of my problem.</div></div><div><br></div><div>--</=
div><div>J=C3=A9r=C3=A9my</div></blockquote>
------=_Part_301_1644708.1352854144070--
------=_Part_300_7596612.1352854144070--
Message from discussion How to keep it all in RAM ?
| Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy |
| ©2013 Google |