[SERVER-33237] Optimize the Range Deleter speed Created: 09/Feb/18  Updated: 29/Oct/23  Resolved: 13/Jun/18

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.2.19, 3.4.13, 3.6.3
Fix Version/s: 3.4.17, 3.6.7, 4.0.1, 4.1.1

Type: Improvement Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: Kevin Pulo
Resolution: Fixed Votes: 2
Labels: bkp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Documented
is documented by DOCS-11809 Docs for SERVER-33237: Optimize the R... Closed
Related
is related to SERVER-37616 Implement tuneable batch size for the... Closed
Backwards Compatibility: Minor Change
Backport Requested:
v4.0, v3.6, v3.4
Sprint: Sharding 2018-04-09, Sharding 2018-05-07, Sharding 2018-05-21, Sharding 2018-06-04, Sharding 2018-06-18
Participants:
Case:
Linked BF Score: 0

 Description   

The sharding range deleter was intentionally implemented to not be fully efficient in order to minimize its interference with MMAP V1. This causes orphaned data to accumulate especially with the recent moveChunk improvements.

With the WiredTiger storage engine, we can let it run at full speed and we should investigate the benefit of directly instantiating an auto-yielding delete stage instead of recreating the index scan phase for each document.



 Comments   
Comment by Kevin Pulo [ 28/Aug/18 ]

The behaviour of this fix differs slightly between MongoDB 3.4 and 3.6+. In both cases, "batch" below refers to (by default) 128 document deletions performed by the Range Deleter.

  • 3.6+:
    • The Range Deleter generates the index plan once per batch. (Previously it re-planned for each document deletion.)
    • rangeDeleterBatchDelayMS occurs after each batch.
    • If _secondaryThrottle is enabled, then waiting for replication occurs after each batch (standard behaviour for 3.4+).
  • 3.4:
    • The Range Deleter generates the index plan:
      • If _secondaryThrottle is enabled, then once per document deletion (as previously).
      • If _secondaryThrottle is disabled, then once per batch. (Previously it re-planned for each document deletion.)
    • rangeDeleterBatchDelayMS occurs after each batch.
    • If _secondaryThrottle is enabled, then waiting for replication occurs after each document deletion (standard behaviour for 3.4).

Note that in 3.4, rangeDeleterBatchDelayMS occurs both when _secondaryThrottle is enabled and disabled (for consistency), even though the re-planning performance improvement only applies when _secondaryThrottle is disabled. This means that in 3.4, it may be necessary to adjust the value of rangeDeleterBatchDelayMS when changing between _secondaryThrottle enabled and disabled (and vice-versa), to avoid unexpected increases or decreases in Range Deleter performance.

Comment by Githook User [ 20/Aug/18 ]

Author:

{'name': 'Kevin Pulo', 'email': 'kevin.pulo@mongodb.com', 'username': 'devkev'}

Message: SERVER-33237 Range deleter avoid query planning for every document.

Custom backport to v3.4, based on 6ed473ed3a122bebc1e932c946fe1c991dbd7ecb.

In v3.4, the excessive query planning is only avoided when _secondaryThrottle
is off.

Also add the rangeDeleterBatchDelayMS server parameter (default 20ms), to give
greater control (when necessary) over range deleter throttling. This delay is
in addition to any _secondaryThrottle replication delays.
Branch: v3.4
https://github.com/mongodb/mongo/commit/581a10bcfc9b755a099a59f8489a5b0e6d5a1746

Comment by Githook User [ 11/Jul/18 ]

Author:

{'username': 'devkev', 'name': 'Kevin Pulo', 'email': 'kevin.pulo@mongodb.com'}

Message: SERVER-33237 Range deleter query plan once per batch.

Rather than once for each deleted document.

Also add the rangeDeleterBatchDelayMS server parameter (default 20ms), to give
greater control (when necessary) over range deleter throttling.

(cherry picked from commit 6ed473ed3a122bebc1e932c946fe1c991dbd7ecb)
Branch: v3.6
https://github.com/mongodb/mongo/commit/ac71cfb02a9f0f4ffad8f97252b498ebc53cece5

Comment by Githook User [ 11/Jul/18 ]

Author:

{'username': 'devkev', 'name': 'Kevin Pulo', 'email': 'kevin.pulo@mongodb.com'}

Message: SERVER-33237 Range deleter query plan once per batch.

Rather than once for each deleted document.

Also add the rangeDeleterBatchDelayMS server parameter (default 20ms), to give
greater control (when necessary) over range deleter throttling.

(cherry picked from commit 6ed473ed3a122bebc1e932c946fe1c991dbd7ecb)
Branch: v4.0
https://github.com/mongodb/mongo/commit/5d6df07e2513577b5c6d55c9342d462d931662d6

Comment by Githook User [ 13/Jun/18 ]

Author:

{'username': 'devkev', 'name': 'Kevin Pulo', 'email': 'kevin.pulo@mongodb.com'}

Message: SERVER-33237 Range deleter query plan once per batch.

Rather than once for each deleted document.

Also add the rangeDeleterBatchDelayMS server parameter (default 20ms), to give
greater control (when necessary) over range deleter throttling.
Branch: master
https://github.com/mongodb/mongo/commit/6ed473ed3a122bebc1e932c946fe1c991dbd7ecb

Generated at Thu Feb 08 04:32:45 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.