Spike of write lock percentage causing high response time
662 views
Skip to first unread message
kllam55
Jan 21, 2011, 2:04:18 PM1/21/11
to mongodb-user
To whom this may concern,
Recently our mongodb instance (1 node) is experiencing an unusual
spike of high write lock percentage (~4%). During these unusual spike
periods the CPU percentage usage went up to 390%+ (it is a quad core)
and the load average was also high (~25-ish). As a result the
response time during these spike period was 1000+ ms. This may sound
like a dumb question but what could be potentially causing these type
of high write lock percentage spikes? One other thing we did was
running mongostat during these periods and we notice that most of the
operations were queries as there were hardly any insert/update/delete
operations at the time. Strangely these spikes usually last for 1 -
2 hours and everything will go back to normal after that (w/o any
intervention).
Any assistance and insight (for what to look for on the next
occurrence) would be greatly appreciate it.
Thanks
King
Recently our mongodb instance (1 node) is experiencing an unusual
spike of high write lock percentage (~4%). During these unusual spike
periods the CPU percentage usage went up to 390%+ (it is a quad core)
and the load average was also high (~25-ish). As a result the
response time during these spike period was 1000+ ms. This may sound
like a dumb question but what could be potentially causing these type
of high write lock percentage spikes? One other thing we did was
running mongostat during these periods and we notice that most of the
operations were queries as there were hardly any insert/update/delete
operations at the time. Strangely these spikes usually last for 1 -
2 hours and everything will go back to normal after that (w/o any
intervention).
Any assistance and insight (for what to look for on the next
occurrence) would be greatly appreciate it.
Thanks
King
kllam55
Jan 21, 2011, 2:07:35 PM1/21/11
to mongodb-user
Just to follow up on this we are running mongodb 1.6.2 on a 64bit
Linux box.
Linux box.
Eliot Horowitz
Jan 22, 2011, 12:42:09 AM1/22/11
to mongod...@googlegroups.com
Hi write lock times generally means you're doing a lot of writes, or
hitting disk a lot.
How many writes/second are you doing?
You should use "iostat -x" to see if you're saturating disk.
If so, you may want to consider sharding.
hitting disk a lot.
How many writes/second are you doing?
You should use "iostat -x" to see if you're saturating disk.
If so, you may want to consider sharding.
> --
> 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.
> For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.
>
>
kllam55
Jan 24, 2011, 1:30:42 PM1/24/11
to mongodb-user
Thanks Eliot. I will keep an eye on mongostats and try running the
iostat command next time when this happens to hopefully track down the
root cause of the spike.
On Jan 21, 9:42 pm, Eliot Horowitz <eliothorow...@gmail.com> wrote:
> Hi write lock times generally means you're doing a lot of writes, or
> hitting disk a lot.
> How many writes/second are you doing?
> You should use "iostat -x" to see if you're saturating disk.
> If so, you may want to consider sharding.
>
iostat command next time when this happens to hopefully track down the
root cause of the spike.
On Jan 21, 9:42 pm, Eliot Horowitz <eliothorow...@gmail.com> wrote:
> Hi write lock times generally means you're doing a lot of writes, or
> hitting disk a lot.
> How many writes/second are you doing?
> You should use "iostat -x" to see if you're saturating disk.
> If so, you may want to consider sharding.
>
> On Fri, Jan 21, 2011 at 2:07 PM,kllam55<klla...@gmail.com> wrote:
> > Just to follow up on this we are running mongodb 1.6.2 on a 64bit
> > Linux box.
>
> > Just to follow up on this we are running mongodb 1.6.2 on a 64bit
> > Linux box.
>
Reply all
Reply to author
Forward
0 new messages