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

remove next_random_sample_size=1000 configuration in the oplog sampling code

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.1.0-rc0
    • Component/s: None
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Sprint:
      Execution Team 2021-06-14, Execution Team 2021-07-12

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              benety.goh Benety Goh
              Reporter:
              keith.bostic Keith Bostic
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: