> 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