Hi Mukesh,
The earlier suggestions from @chris and @Doug_Duncan are great starting points. Definitely identify whether the query volume is targeting sharded or unsharded collections, and review your queries and data distribution for any sharded collections on the affected shard. If there are many unsharded collections with rep2 as their primary shard, this difference in network traffic may be expected.
Queries for sharded collections are distributed based on the shard key values. Chunks in a sharded collection are balanced based on roughly equal distribution of chunks according to migration thresholds. There are scenarios where a sharded collection may be balanced by policy but still have an unequal distribution of workload. A good choice of shard key will, on average, distribute your workload appropriately.
Some other considerations for balancing:
- Assuming the disproportionate queries are for sharded collections, check if these collections have any jumbo chunks – if so, these will show as
jumbo in the output of sh.status(true) . Jumbo chunks are considered too large to move and ignored by the balancer. Jumbo chunks can sometimes be manually divisible, but are usually caused by a poor choice of shard key. See: Clear jumbo Flag .
- Does the distribution of estimated docs and data per chunk look reasonable based on
db.collection.getShardDistribution() and any shard tagging you may be using to influence the balancer policy?
- Are you deleting documents from sharded collections that might create empty chunks based on your shard key? For example, if your shard key is based on a creation date and you expire or delete old documents there will be older chunk ranges that will never be used for new data. Sparsely populated chunks will not be consolidated automatically, but you can manually merge chunks if appropriate.
If chunks are balanced as expected but data/docs distribution is not, you may have empty chunks, jumbo chunks, or a poor choice of shard key.
Also as mentioned earlier, MongoDB 3.0 is an end of life release series. As always, I’d recommend upgrading to the final minor release (3.0.15) and planning an upgrade to a supported release series (currently 3.6 or higher). This is unlikely to affect your query distribution issue, but MongoDB 3.0.4 was released in June, 2015 and you are missing out on 2 years of maintenance and stability updates for the 3.0 release series.
If you are using Ops Manager legally in a production environment, you should also be able to raise a case on the Support Portal as per your MongoDB Enterprise Advanced subscription 
. However, MongoDB 3.0 is well out of support so I’ll assume this is a test/development environment.
Regards,
Stennie
