Date: Wed, 22 Aug 2012 09:02:20 -0700 (PDT)
From: "A. Jesse Jiryu Davis" <je...@10gen.com>
To: mongodb-user@googlegroups.com
Message-Id: <888c3cb8-31ae-46f2-a493-dca00bf1c9cd@googlegroups.com>
In-Reply-To: <458e5a77-f176-4c4a-a368-db2d5ab230cc@googlegroups.com>
References: <a0d74472-ce37-4f10-b203-c57c71f43440@googlegroups.com>
 <CALKyTE4p8MwDUzpbO5VAufFhAMCSfv=zWtMfceESFANoAgv5Og@mail.gmail.com>
 <34edabd2-bc92-4d84-bdf6-82611fb24dca@googlegroups.com>
 <CALKyTE4Wa9SSuU5fL8ujXMDS9gv4JPbMGrCBmm3qEksPBn4JAA@mail.gmail.com>
 <458e5a77-f176-4c4a-a368-db2d5ab230cc@googlegroups.com>
Subject: Re: [mongodb-user] Why SSD's result in less time write lock when DB
 fits completely in RAM?
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_245_21615319.1345651340880"

------=_Part_245_21615319.1345651340880
Content-Type: multipart/alternative; 
	boundary="----=_Part_246_28396011.1345651340880"

------=_Part_246_28396011.1345651340880
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Mongo doesn't really have a notion of "straight to disk" writes. However, 
Mongo does (by default) fsync all changed data from memory to disk once a 
minute. During this fsync the write lock is held, so the duration of fsyncs 
contributes to the lock percentage. Changed memory will probably be spread 
out in different locations, so the disk will have to seek around to fsync 
all the changed data. SSDs are faster at seeking, hence faster at fsyncing, 
hence Mongo holds the write lock less while fsyncing.

Can you confirm that your fsync times are shorter? If your mongod is in MMS 
then you'll see the "background flush avg" statistic be lower with SSDs.

On Wednesday, August 22, 2012 11:02:45 AM UTC-4, Shi Shei wrote:
>
> Yes, journalling is off. 
> We're running 3 shards, each having 3 members, each member having 96 GB of 
> RAM and 320 GB of SSD, in case it matters.
>
> Thank you for the links. I read the articles but didn't find any new 
> information nor the answer to my initial question.
>
> I'd be glad if you or someone else have some other pointers.
>
>
> On Wednesday, August 22, 2012 1:34:23 PM UTC+2, Sammaye wrote:
>>
>> Journalling is off? Hmmm, ok.
>>
>> But yea, then that's one thing that doesn't effect write lock.
>>
>> You have to take into account the speed difference in general between the 
>> two disks you are comparing however have you read: 
>> http://www.mongodb.org/display/DOCS/SSD
>>
>> For general info here is another link I liked: 
>> http://blog.serverdensity.com/mongodb-performance-ssds-vs-spindle-sas-drives/
>>
>> I cannot invest the time to personally answer the question fully but 
>> these links should help and give a bit of reading material until some one 
>> can.
>>
>> On 22 August 2012 12:23, Shi Shei <QTRAUR...@spammotel.com> wrote:
>>
>>> What do you mean with "the amount "safe" straight to disk writes"? We 
>>> don't "save straight so disk". Journalling is off either.
>>>
>>>
>>> On Wednesday, August 22, 2012 12:46:34 PM UTC+2, Sammaye wrote:
>>>
>>>> One reason could be the amount "safe" straight to disk writes you are 
>>>> doing.
>>>>
>>>> On 22 August 2012 10:40, Shi Shei <QTRAUR...@spammotel.com> wrote:
>>>>
>>>>> We observed a dramatically decrease of write lock time when we 
>>>>> replaced spindle disks by SSD's even though the complete database fits in 
>>>>> RAM. Why is it so? 
>>>>>
>>>>> I thought that mongo writes to memory mapped files, so the global (or 
>>>>> DB) write lock is not that evil since the DB is locked only when writes go 
>>>>> to these memory mapped files in RAM and not to disk. To my knowledge, 
>>>>> flushing every minute the data to disk is a background process, not locking 
>>>>> at all other things.
>>>>>
>>>>> Hence my question, why SSD's help to decrease write lock time?
>>>>>
>>>>>  -- 
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "mongodb-user" group.
>>>>> To post to this group, send email to mongod...@googlegroups.com
>>>>>
>>>>> To unsubscribe from this group, send email to
>>>>> mongodb-user...@**googlegroups.com
>>>>>
>>>>> See also the IRC channel -- freenode.net#mongodb
>>>>>
>>>>
>>>>  -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "mongodb-user" group.
>>> To post to this group, send email to mongod...@googlegroups.com
>>> To unsubscribe from this group, send email to
>>> mongodb-user...@googlegroups.com
>>> See also the IRC channel -- freenode.net#mongodb
>>>
>>
>>
------=_Part_246_28396011.1345651340880
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Mongo doesn't really have a notion of "straight to disk" writes. However, M=
ongo does (by default) fsync all changed data from memory to disk once a mi=
nute. During this fsync the write lock is held, so the duration of fsyncs c=
ontributes to the lock percentage. Changed memory will probably be spread o=
ut in different locations, so the disk will have to seek around to fsync al=
l the changed data. SSDs are faster at seeking, hence faster at fsyncing, h=
ence Mongo holds the write lock less while fsyncing.<div><br></div><div>Can=
 you confirm that your fsync times are shorter? If your mongod is in MMS th=
en you'll see the "background flush avg" statistic be lower with SSDs.<br><=
br>On Wednesday, August 22, 2012 11:02:45 AM UTC-4, Shi Shei wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">Yes, journalling is off. <br>We're run=
ning 3 shards, each having 3 members, each member having 96 GB of RAM and 3=
20 GB of SSD, in case it matters.<br><br>Thank you for the links. I read th=
e articles but didn't find any new information nor the answer to my initial=
 question.<br><br>I'd be glad if you or someone else have some other pointe=
rs.<br><br><br>On Wednesday, August 22, 2012 1:34:23 PM UTC+2, Sammaye wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">Journalling is off? Hmmm, ok.<br>=
<br>But yea, then that's one thing that doesn't effect write lock.<br><br>Y=
ou have to take into account the speed difference in general between the tw=
o disks you are comparing however have you read: <a href=3D"http://www.mong=
odb.org/display/DOCS/SSD" target=3D"_blank">http://www.mongodb.org/<wbr>dis=
play/DOCS/SSD</a><br>
<br>For general info here is another link I liked: <a href=3D"http://blog.s=
erverdensity.com/mongodb-performance-ssds-vs-spindle-sas-drives/" target=3D=
"_blank">http://blog.serverdensity.com/<wbr>mongodb-performance-ssds-vs-<wb=
r>spindle-sas-drives/</a><br>
<br>I cannot invest the time to personally answer the question fully but th=
ese links should help and give a bit of reading material until some one can=
.<br><br><div class=3D"gmail_quote">On 22 August 2012 12:23, Shi Shei <span=
 dir=3D"ltr">&lt;<a>QTRAUR...@spammotel.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">What do you mean with "the amount "safe" str=
aight to disk writes"? We don't "save straight so disk". Journalling is off=
 either.<div>
<br><br>On Wednesday, August 22, 2012 12:46:34 PM UTC+2, Sammaye wrote:</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div>One reason could be the amou=
nt "safe" straight to disk writes you are doing.<br>
<br></div><div class=3D"gmail_quote"><div>On 22 August 2012 10:40, Shi Shei=
 <span dir=3D"ltr">&lt;<a>QTRAUR...@spammotel.com</a>&gt;</span> wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div>We observed a dramatically decrea=
se of write lock time when we replaced spindle disks by SSD's even though t=
he complete database fits in RAM. Why is it so? <br>

<br>I thought that mongo writes to memory mapped files, so the global (or D=
B) write lock is not that evil since the DB is locked only when writes go t=
o these memory mapped files in RAM and not to disk. To my knowledge, flushi=
ng every minute the data to disk is a background process, not locking at al=
l other things.<br>

<br>Hence my question, why SSD's help to decrease write lock time?</div><sp=
an><font color=3D"#888888"><div><br>

<p></p>

-- <br>
You received this message because you are subscribed to the Google<br>
Groups "mongodb-user" group.<br></div>
To post to this group, send email to <a>mongod...@googlegroups.com</a><div>=
<br>
To unsubscribe from this group, send email to<br>
</div><a>mongodb-user...@<u></u>googlegroups.<wbr>com</a><div><br>
See also the IRC channel -- <a href=3D"http://freenode.net#mongodb" target=
=3D"_blank">freenode.net#mongodb</a><br>
</div></font></span></blockquote></div><br>
</blockquote><div><div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google<br>
Groups "mongodb-user" group.<br>
To post to this group, send email to <a>mongod...@googlegroups.com</a><br>
To unsubscribe from this group, send email to<br>
<a>mongodb-user...@googlegroups.<wbr>com</a><br>
See also the IRC channel -- <a href=3D"http://freenode.net#mongodb" target=
=3D"_blank">freenode.net#mongodb</a><br>
</div></div></blockquote></div><br>
</blockquote></blockquote></div>
------=_Part_246_28396011.1345651340880--

------=_Part_245_21615319.1345651340880--