Re: 3.2.2 Replica set, secondary nodes freezes

From: Ankur Raina <ankur.raina@xxxxxxxxxxx>
To: mongodb-user <mongodb-user@xxxxxxxxxxxxxxxx>
Date: Mon, 18 Apr 2016 23:21:42 -0700 (PDT)
Why ads?


Hi Lucas,

I have replica set set up of 5 nodes, one primary, 4 secondaries, where 
only 2 are used by application. Mongo 3.2.2, ubuntu 14.04 lts, 6 cores, 
16gb ram, SSD. 

Are all these mongod instances running on separate physical/virtual 
machines? If this is a production cluster, please ensure following MongoDB 
3.2 production notes 
<https://docs.mongodb.org/manual/administration/production-notes/>.

Please also go through the WiredTiger specific recommendations 
<https://docs.mongodb.org/manual/administration/production-notes/#id3> if 
you are using this storage engine.

From time to time, on all secondaries (even on not used by application), 
cpu load peaks up to 100%, all used by mongo, the connections are hung. 
Peak can last up to 30 minutes.

No obvious reason. I Thought, that it could be bad indexing, strange 
queries, but it’s happening also on idling nodes…

Please note that there is no real idling unless no data is being written to 
the replica set primary and all secondaries have no replication lag to 
catch up on. You should also look for index build in the logs during this 
time. e.g:

cat mongod.log|grep INDEX

If you find index builds during this time, please note that a foreground 
index blocks operations on a database until the index build is complete. 
The foreground index will be built on the primary first and then replicated 
to all secondaries. In that case, the recommended alternative would be to build 
indexes in the background 
<https://docs.mongodb.org/manual/core/index-creation/#background-construction>. 
For another alternative, please see Build Indexes on Replica Sets 
<https://docs.mongodb.org/manual/tutorial/build-indexes-on-replica-sets/#build-indexes-on-replica-sets>
.

You should check the mongod logs on the secondaries and compare with 
primaries for better info on what is running during this time period. You 
can use mtools <https://github.com/rueckstiess/mtools> for analysing these 
logs and create a visual representation of queries that run during this 
time. This MongoDB presentation on Diagnostics and Debugging 
<https://www.mongodb.com/presentations/diagnostics-and-debugging-3-0-the-return-of-sherlock-holmes
should help you along the way. 

ps. there are only 30 milion records in that DB.

The performance of any database system depends on several factors and might 
not always have a proportional ratio to the number of documents. Size of 
each document, types of queries running, hardware and software 
configurations, other processes running on the machine, bad indexes, and 
deployment architecture may all have a significant impact.

I hope this information helps you drill down to the exact factors that are 
in effect during this time period as the graphs that you have put here are 
not enough to justify the reasons behind bad performance of your 
deployment. 

Regards
Ankur


-- 
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: https://docs.mongodb.org/manual/support/
--- 
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+unsubscribe@xxxxxxxxxxxxxxxx.
To post to this group, send email to mongodb-user@xxxxxxxxxxxxxxxx.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/9490b6ba-e7e2-4a1c-827a-e89608373b04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Why ads?