Received: by 10.58.133.100 with SMTP id pb4mr6220515veb.6.1345647776236;
        Wed, 22 Aug 2012 08:02:56 -0700 (PDT)
X-BeenThere: mongodb-user@googlegroups.com
Received: by 10.52.93.38 with SMTP id cr6ls1351473vdb.8.gmail; Wed, 22 Aug
 2012 08:02:46 -0700 (PDT)
Received: by 10.52.75.36 with SMTP id z4mr1244543vdv.14.1345647766326;
        Wed, 22 Aug 2012 08:02:46 -0700 (PDT)
Date: Wed, 22 Aug 2012 08:02:45 -0700 (PDT)
From: Shi Shei <QTRAURFUI...@spammotel.com>
To: mongodb-user@googlegroups.com
Message-Id: <458e5a77-f176-4c4a-a368-db2d5ab230cc@googlegroups.com>
In-Reply-To: <CALKyTE4Wa9SSuU5fL8ujXMDS9gv4JPbMGrCBmm3qEksPBn4JAA@mail.gmail.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>
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_884_16451613.1345647765874"

------=_Part_884_16451613.1345647765874
Content-Type: multipart/alternative; 
	boundary="----=_Part_885_13748805.1345647765874"

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

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 <javascript:>>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<javascript:>
>> To unsubscribe from this group, send email to
>> mongodb-user...@googlegroups.com <javascript:>
>> See also the IRC channel -- freenode.net#mongodb
>>
>
>
------=_Part_885_13748805.1345647765874
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

Yes, journalling is off. <br>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.<br><br>Thank you for the links. I read the 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 pointers.<br><br><br>On Wednesday, August 22, 2012 1:34:23 PM UTC+2, Sammaye wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-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>You have to take into account the speed difference in general between the two disks you are comparing however have you read: <a href="http://www.mongodb.org/display/DOCS/SSD" target="_blank">http://www.mongodb.org/<wbr>display/DOCS/SSD</a><br>
<br>For general info here is another link I liked: <a href="http://blog.serverdensity.com/mongodb-performance-ssds-vs-spindle-sas-drives/" target="_blank">http://blog.serverdensity.com/<wbr>mongodb-performance-ssds-vs-<wbr>spindle-sas-drives/</a><br>
<br>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.<br><br><div class="gmail_quote">On 22 August 2012 12:23, Shi Shei <span dir="ltr">&lt;<a href="javascript:" target="_blank" gdf-obfuscated-mailto="1DMlZRFqsssJ">QTRAUR...@spammotel.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What do you mean with "the amount "safe" straight 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:</div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>One reason could be the amount "safe" straight to disk writes you are doing.<br>
<br></div><div class="gmail_quote"><div>On 22 August 2012 10:40, Shi Shei <span dir="ltr">&lt;<a>QTRAUR...@spammotel.com</a>&gt;</span> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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? <br>

<br>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.<br>

<br>Hence my question, why SSD's help to decrease write lock time?</div><span><font color="#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="http://freenode.net#mongodb" target="_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 href="javascript:" target="_blank" gdf-obfuscated-mailto="1DMlZRFqsssJ">mongod...@googlegroups.com</a><br>
To unsubscribe from this group, send email to<br>
<a href="javascript:" target="_blank" gdf-obfuscated-mailto="1DMlZRFqsssJ">mongodb-user...@<wbr>googlegroups.com</a><br>
See also the IRC channel -- <a href="http://freenode.net#mongodb" target="_blank">freenode.net#mongodb</a><br>
</div></div></blockquote></div><br>
</blockquote>
------=_Part_885_13748805.1345647765874--

------=_Part_884_16451613.1345647765874--