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

Investigate using "first" fit block allocation for the Oplog

    • Type: Icon: Task Task
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • Storage Execution

      Suppose the following sequence of steps:

      • Oplog current size equals the maximum oplog size
      • Oplog suddenly gets an influx of new entries and grows the file size to 2x its original size before truncation can happen. These new entries get appended at the end of the file.
      • Truncate executes and suddenly liberates a huge chunk of blocks near the beginning of the file.

      With the current block allocation algorithm ("best" fit) we see that new allocations will happen towards the end of the file as new chunks are liberated and not use the massive chunk of empty space left towards the beginning.

      As a result, the oplog file is artificially larger than it should be and will take a really long time to release space back to disk. WT can only release resources if there are no blocks active at the end of the file.

      One possibility to avoid this would be to use the "first" fit algorithm in the oplog as it would force new allocations to happen towards the beginning of the file. This would make WT release space faster to disk at the potential cost of file fragmentation.

      If the result of this ticket is that we should use the "first" fit algorithm we should open up other tickets to investigate applying this to other similar collections (capped append-only collections)

            Assignee:
            backlog-server-execution [DO NOT USE] Backlog - Storage Execution Team
            Reporter:
            jordi.olivares-provencio@mongodb.com Jordi Olivares Provencio
            Votes:
            0 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated: