Why SSD's result in less time write lock when DB fits completely in RAM?

162 views
Skip to first unread message

Shi Shei

unread,
Aug 22, 2012, 5:40:20 AM8/22/12
to mongod...@googlegroups.com
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?

Sam Millman

unread,
Aug 22, 2012, 6:46:34 AM8/22/12
to mongod...@googlegroups.com
One reason could be the amount "safe" straight to disk writes you are doing.


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

Shi Shei

unread,
Aug 22, 2012, 7:23:51 AM8/22/12
to mongod...@googlegroups.com
What do you mean with "the amount "safe" straight to disk writes"? We don't "save straight so disk". Journalling is off either.

Sam Millman

unread,
Aug 22, 2012, 7:34:23 AM8/22/12
to mongod...@googlegroups.com
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.

Shi Shei

unread,
Aug 22, 2012, 11:02:45 AM8/22/12
to mongod...@googlegroups.com
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.

A. Jesse Jiryu Davis

unread,
Aug 22, 2012, 12:02:20 PM8/22/12
to mongod...@googlegroups.com
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.

Shi Shei

unread,
Aug 24, 2012, 5:52:16 PM8/24/12
to mongodb-user
> During this fsync the write lock is held, so the duration of fsyncs contributes to the lock percentage.

Are you sure of this? To my knowledge this is a background operation
without locking. Furthermore, before using SSD's, flush time was
sometimes more than a minute. Since it's flushed every minute, the DB
would have be locked all the time - but it wasn't.

> Can you confirm that your fsync times are shorter?

Of course, they are shorter. Not comparable to before. With SSD's it
takes at most a few seconds, with spindls disks it could take a minute
or more.

On Aug 22, 6:02 pm, "A. Jesse Jiryu Davis" <je...@10gen.com> wrote:
> 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...
>
> >> 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
Reply all
Reply to author
Forward
0 new messages