The use of the next_random_sample_size option when creating random cursors on a WiredTiger record store is not applicable anymore due to unbalanced trees being a non-issue in recent MongoDB releases and customer deployments. The work for this ticket involves removing the use of this option from the oplog sampling code in wiredtiger_record_store.cpp for 5.1 and to evaluate removing the support for this option in the WiredTiger storage engine at a later time.

PREVIOUS SUMMARY: Investigate slow random cursor operations on oplog

Random cursors can be quite slow on a multi-GB oplog table.

A customer has experienced slow startup times in 4.2 that they didn't see in 4.0.  Based on their logs mongod is spending a lot of time iterating a random cursor though the oplog — in one case it takes 15 minutes to perform 993 cursor->next() calls on a ~26GB oplog.  The oplog had only 62590 records, so the average record size is 100s of KB.

See WT-7373 for more discussion.