Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My setup: I have 2 hosts, and 2 shards each.

  • Host1 has 2 shards, and is the master of the replicas
  • host2 has the secondaries of the 2 shards.


  • host1: shard1 (repset1),shard2 (repset2)
  • host2: shard1 (repset1),shard2 (repset2)

There's also a 3rd host that acts as arbitrer.

I have 50 threads writing randomly to both shards (using a hash) via mongos with REPLICA_SAFE WriteConcern set on each insert.

The questions:

  1. mongostat displays about 90% locked for both shards in host1 and about 1% locked on host2. Since I use REPLICA_SAFE which supposedly writes to both servers shouldn't the locks be the same?
  2. mongostat reports qr=30 for both shards of host1, and qw=0 always. Since I perform only writes how is this possible? Moreover on host2 all queues are reported 0. Faults are abut the same in all shards/hosts (arround 80).
  3. netIn/netOut on the secondaries (host2) are always about 200bytes/sec. Too low.
  4. mongos has 53 connections, host1's shards have 71 and 71 and host2's shards have 9 and 8. How is this?
share|improve this question

migrated from Nov 7 '12 at 18:05

This question came from our site for professional and enthusiast programmers.

Which version of mongo are you running. If >= 2.2.X are those lock statistics for the collection in question, global or aggregate? – daveh Nov 19 '12 at 7:30

Be careful with running multiple instances of mongod on one host. They are competing in system unitlization:

Or run vm's with dedicated RAM and CPU's (thats the way you could use those 24Core System more efficiently with MongoDB ;)

share|improve this answer


It looks like you are using mongo < 2.0 if you are not, that may change things. You say you are using REPLICA_SAFE, which W level are you using? If its w:1 then you are simply confirming the writes to your primary have succeeded, you should use w:2 to confirm the writes have reached your secondary.

  1. Replication will account for this. Your inserts are taking a write lock as they insert and this is blocking the replication from reading the data to replicate.

  2. Reinforces point 1. Your replication reads are queueing behind the writes from the inserts. Faults are probably the issue here as your system needs to page into RAM things that are to be read in for replication which is yielding its lock. You are also likely to be seeing contention between your two primaries for RAM for the reasons Marc mentioned.

  3. Seems low, but cant be certain. Likely that your systems are waiting to page data into RAM or for a Write lock in order to replicate it.

  4. You can see which connections go where from within the logfiles. Without knowing what is where i could not tell you why. That said the number of connections here does not seem unreasonable.

share|improve this answer
I'm using mongo 2.2 – sivann Nov 20 '12 at 16:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .