Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-55821

remove next_random_sample_size=1000 configuration in the oplog sampling code

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 5.1.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • Fully Compatible
    • ALL
    • Execution Team 2021-06-14, Execution Team 2021-07-12

      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.

            benety.goh@mongodb.com Benety Goh
            keith.bostic@mongodb.com Keith Bostic (Inactive)
            0 Vote for this issue
            9 Start watching this issue