Re: Global Lock for more than 4 minutes on Mongo 3.0 with wiredTiger

From: Kevin Adistambha <kevinadi@xxxxxxxxxxx>
To: mongodb-user <mongodb-user@xxxxxxxxxxxxxxxx>
Date: Wed, 4 May 2016 19:11:43 -0700 (PDT)
Why ads?


Hi Abhishek

I should have specified that I used Flashback to do this. I had also 
mentioned that I am sending *prod like* traffic, but with Flashback, I am 
sending the *actual prod traffic* to this hidden node. My workload is read 
heavy, so 90% of my traffic is reads and using secondary preference I am 
sending all that traffic to secondaries. And via Flashback, that same 
traffic gets replayed on 3.0 node.

Let me understand this correctly:

   - Your current prod setup consists of three nodes, and your application 
   uses Read Preference of secondaryPreferred 
   <https://docs.mongodb.org/v2.6/core/read-preference/
   - Currently you are testing MongoDB 3.0 using the WiredTiger engine, set 
   it up as a hidden Secondary, and use Flashback to replay all traffic to the 
   Primary 
   - Your prod traffic is 90% reads, and 10% upserts 
   - I presume you send only the read traffic to the 3.0 node, since 
   Secondaries cannot perform writes 

Please let me know if my understanding of the situation is incorrect.

With that information, do you still think that this “load testing” is 
creating a resource contention?

If my understanding is correct, there are different factors at play in this 
setup:

   - Currently in your prod system, the read traffic is probably spread 
   across the three 2.6 nodes 
   - If you are sending *all* read traffic to the 3.0 node, that node could 
   be overburdened since:
      1. It must also act as a Secondary, with the aforementioned 
      limitation (i.e. reads will block on it during oplog application) 
      2. Load that were likely spread across three nodes are now 
      concentrated on this single node 
   - The high WiredTiger cache eviction rate could mean that it frequently 
   need to go to disk to satisfy the read queries because your working set 
   does not fit in RAM, further degrading performance 
   - The WiredTiger cache seems to be configured at 1 GB. How much RAM does 
   this 3.0 machine has? Was the WiredTiger cache size deliberately set to 1 
   GB, or was it left at default? 

There are some things that maybe you could try:

   - Since this is a load testing exercise, data integrity during the test 
   is less important vs. the ability of the server to handle load. You could 
   remove the 3.0 node from the prod replica set, configure it as a new 
   single-node replica set, and use Flashback to simulate your prod load (both 
   read and write) on it 
   - However, a more representative load testing is using an actual 
   three-node 3.0 replica set that mirrors your prod deployment. Using this 
   testing setup, you could also test failure scenario under load (e.g. what 
   happens when a Secondary went offline during heavy read load) 

Having said that, please be advised that using Secondary read to provide 
extra capacity for reads is generally not recommended 
<https://docs.mongodb.org/v2.6/core/read-preference/#counter-indications>. 
For more details regarding this, please see Can I use more replica nodes to 
scale <http://www.askasya.com/post/canreplicashelpscaling/> blog post.

Best regards,
Kevin


-- 
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/ab724998-c1fa-4abb-826e-38f686249d21%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Why ads?