Initial sync index build memory limits
Parent: Index build resource limits (maxNumActiveUserIndexBuilds, disk space) · Published reference · snapshot 2026-10-30
↓ Facts as markdownall context files
Source-anchored research for Initial sync index build memory limits. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Structure and components
- Very low per-index budgets can also lengthen builds: a multi-index build divides memory across indexes, and SERVER-114768 reports that small budgets require intermediate merges of spill ranges. The server's sorter design confirms that spill iterators themselves consume part of the memory budget. (high confidence) [source]
How it works
- More index-build memory does not guarantee faster logical initial sync. SERVER-111871 explicitly questioned the benefit of the increased default; SERVER-114768 reports cases where increasing memory lengthened builds when the indexed data still exceeded memory and required spilling. (high confidence) [source]
- Alibaba Cloud documents initial synchronization OOM when adding a node among the potential consequences of excessive collections and indexes. Its explanation includes in-memory WiredTiger dhandle overhead for open objects. This scopes diagnosis beyond the index sorter's configured budget; it does not prove that raising or lowering that budget fixes such failures. (low confidence) [source]
Measurements and reference values
- MongoDB introduced dedicated initial sync index-build controls in 8.2, with backports to 8.0.13 and 7.0.26. The default budget is 10% of available RAM, bounded below by 200 MB and above by 16384 MB; treating 200 MB as the universal initial sync default is incorrect for these releases. (high confidence) (verified as of 2026-10-30) [source]
- initialSyncIndexBuildMemoryPercentage, initialSyncIndexBuildMemoryMinMB, and initialSyncIndexBuildMemoryMaxMB control the initial sync budget. The percentage accepts 0 through 80; the minimum and maximum parameters each accept 50 through 10000000 MB. All three support startup and runtime configuration; acceptance at runtime does not establish that an already-running sorter is resized. (high confidence) (verified as of 2026-10-30) [source]
- The general maxIndexBuildMemoryUsageMegabytes setting defaults to 200 MB and shares its budget among indexes built by one createIndexes command. Index-build memory is separate from WiredTiger cache memory, so a small WiredTiger cache setting alone does not cap the index-build allocation. (high confidence) (verified as of 2026-10-30) [source]
- Percona's July 30, 2026 technical-preview announcement for its own MongoDB 8.3 distribution states that initial sync index builds use a tunable, bounded 10% of available RAM by default. This is distribution-specific confirmation, not an independent experimental validation of MongoDB's allocation algorithm or performance improvement. (low confidence) (verified as of 2026-07-30) [source]
Comparisons and alternatives
- Index builds use an external sorter: collection scanning generates index keys, which are sorted in memory and spilled to temporary disk files as necessary. Reaching the sorter budget therefore can cause disk I/O rather than itself proving an out-of-memory failure. (medium confidence) [source]
Facts and statements
- SERVER-102428 documented a logical initial sync accounting/allocation defect: secondary indexes shared maxIndexBuildMemoryUsageMegabytes while the simultaneously built _id index received an additional full allocation. The issue lists fixes in 8.2.0-rc0, 8.1.2, 8.0.13 and 7.0.26. This is historical defect evidence, not a description of all current versions. (low confidence) (verified as of 2025-09-29) [source]
- SERVER-114807 attributes avoidable per-key memory overhead to BSON serialization and sorter serialization observed during the initial-sync investigation. Its public description supplies neither a measured overhead factor nor a demonstrated remediation result. (low confidence) [source]
- Generic index-build memory consumption is separate from the WiredTiger cache. A sorter-memory parameter should therefore not be interpreted as a ceiling on all memory consumed by mongod during initial sync. (low confidence) [source]
Children
- Initial-sync index sorter spill and temporary disk capacity (frontier)
- Per-index memory allocation in multi-index builds (frontier)
- Index key serialization memory overhead (frontier)
Frontier under this node: Index key serialization memory overhead, Initial-sync index sorter spill and temporary disk capacity, Per-index memory allocation in multi-index builds