SERVER-9394

optimize secondaries to not create excessive load on the primary under certain scenarios

1 files changed, 18 insertions, 0 deletions

diff --git a/src/mongo/db/repl/bgsync.cpp b/src/mongo/db/repl/bgsync.cpp
index 1a27a095d1e..95f802acc65 100644
--- a/src/mongo/db/repl/bgsync.cpp
+++ b/src/mongo/db/repl/bgsync.cpp
@@ -28,6 +28,10 @@
 
 namespace mongo {
 namespace replset {
+
+    int SleepToAllowBatchingMillis = 2;
+    const int BatchIsSmallish = 40000; // bytes
+
     MONGO_FP_DECLARE(rsBgSyncProduce);
 
     BackgroundSync* BackgroundSync::s_instance = 0;
@@ -328,6 +332,20 @@ namespace replset {
             while (!inShutdown()) {
 
                 if (!r.moreInCurrentBatch()) {
+                    int bs = r.currentBatchMessageSize();
+                    if( bs > 0 && bs < BatchIsSmallish ) {
+                        // on a very low latency network, if we don't wait a little, we'll be 
+                        // getting ops to write almost one at a time.  this will both be expensive
+                        // for the upstream server as well as postentiallyd efating our parallel 
+                        // application of batches on the secondary.
+                        //
+                        // the inference here is basically if the batch is really small, we are 
+                        // "caught up".
+                        //
+                        dassert( !Lock::isLocked() );
+                        sleepmillis(SleepToAllowBatchingMillis);
+                    }
+  
                     if (theReplSet->gotForceSync()) {
                         return;
                     }