If a large migration is occurring in a collection with high insert rate, it's likely that repeated splitVector commands will be triggered by these inserts. Because the collection metadata distributed lock is taken, the split will (correctly) fail, but not before the splitVector command is run on the mongod and the config server is checked. If the chunk to be split is the $max or $min chunk, the amount of inserted data to the chunk is not changed, and every subsequent update and insert to these chunks will trigger a splitVector and splitChunk command.

One optimization for all splits would be to have the mongos itself check the distributed lock, to avoid the splitVector if the split will just fail. For $max/$min inserts, we need to either reset _dataWritten or back off in some other way.

Can be seen occurring in http://buildbot.mongodb.org/builders/Linux%2064-bit%20v8/builds/3032/steps/test_3/logs/stdio/text
when the migration in bigMapReduce.js starting here :

 m30000| Wed Feb 22 07:15:59 [conn5] moveChunk request accepted at version 10|137
 m30000| Wed Feb 22 07:15:59 [conn5] moveChunk number of documents: 0

results in ~150 splitVector requests from a single mongos.