Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-5587

Limit how many checkpoints are dropped by a subsequent checkpoint

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • None
    • WT10.0.0, 4.2.4, 4.3.4, 4.0.17, 3.6.19, 4.7.0
    • None
    • None
    • 2
    • Storage Engines 2020-02-24
    • v4.2, v4.0, v3.6

    Description

      Summary:
      Only drop a maximum of 4 previous checkpoints, during a checkpoint, so the first checkpoint after a hot backup cursor is closed doesn't take a huge amount of time to complete.


      There is code in checkpoint that cleans up obsolete checkpoints as soon as they become obsolete. Significant parts of that cleanup happen while holding locks that interrupt other operations (like opening cursors in some cases). When a backup cursor is open for a long period of time a lot of checkpoints are accumulated, and those checkpoints all become eligible for cleanup as soon as the backup cursor is closed.

      We should limit the number of checkpoint handles cleaned up with each checkpoint. My recommendation would be cleaning up between 2 and 4 checkpoints per file per checkpoint.

      Attachments

        Issue Links

          Activity

            People

              keith.bostic@mongodb.com Keith Bostic
              alexander.gorrod@mongodb.com Alexander Gorrod
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: