WiredTiger cache pressure and write tickets during index builds
Parent: Index build resource limits (maxNumActiveUserIndexBuilds, disk space) · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for WiredTiger cache pressure and write tickets during index builds. 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.
How it works
- Increasing storage-engine ticket counts when CPU, disk, or cache is already saturated can worsen contention and latency. Alibaba recommends finding the bottleneck first; MongoDB warns that changing the concurrency setting can cause performance problems. (medium confidence) [source]
- Percona warns that index builds need CPU and I/O resources and brief database locks; an already near-capacity deployment can suffer an outage. Treat remaining workload capacity as a constraint when scheduling index creation. (low confidence) [source]
Problems, failure modes and limitations
- Alibaba documents that secondary nodes consume write tickets while applying oplog entries, despite not accepting ordinary application writes. Exhaustion can increase replication lag; read operations can also slow replay indirectly by competing for CPU, disk I/O, and WiredTiger cache. (low confidence) [source]
Comparisons and alternatives
- When WiredTiger cache usage reaches an eviction trigger, application threads can be recruited to perform eviction instead of their requested work. Evicting modified pages can require disk writes, adding latency under write pressure. (high confidence) [source]
- MongoDB introduced default dynamic read/write ticket adjustment in 7.0. With dynamic admission, low available-ticket counts alone do not establish overload; inspect queued operations and observed latency rather than assuming a fixed pool of 128 is always active. (high confidence) (verified as of 2026-09-11) [source]
Facts and statements
- MongoDB 8.3 documentation explicitly warns that increasing maxNumActiveUserIndexBuilds permits more concurrent index-build requests at the cost of increased WiredTiger cache pressure. (low confidence) (verified as of 2026-10-30) [source]
- The maxIndexBuildMemoryUsageMegabytes budget governs the external sorter, whose sorted runs spill to temporary disk files; MongoDB documents index-build memory as separate from WiredTiger cache memory. These are distinct resource budgets. (medium confidence) [source]
- Hybrid index builds scan collection data and bulk-load sorted keys while intercepting concurrent inserts, updates, and deletes in an internal side-writes table. That table remains active for the duration of the build. (low confidence) [source]
- Read and write tickets admit concurrent operations into the storage engine using separate pools. Operations unable to obtain a ticket queue, so sustained write-ticket depletion can increase write latency. (high confidence) [source]
- SERVER-48617 documents a historical createIndexes deadlock: waiting command threads held global IX locks and write tickets, exhausting the pool while index-build workers also needed tickets. The issue lists fixes in 4.4.2 and 4.7.0; it does not establish that current releases retain this defect. (low confidence) [source]
- For slowdowns observed during index builds, correlate ticket availability and queued operations with cache eviction, CPU, disk utilization, latency, and replication lag before tuning concurrency. This diagnostic recommendation combines Percona dashboard guidance with Alibaba parameter guidance. (medium confidence) [source]
- The index-build design separates external sorting from bulk-loading sorted keys into a WiredTiger index table. maxIndexBuildMemoryUsageMegabytes controls sorter spilling; it should not be interpreted as a ceiling on total mongod memory or all WiredTiger allocations. (medium confidence) [source]
- The index-build design records concurrent writes in a side-writes table and applies them after collection scanning and key loading. Early draining permits further writes, so additional changes can arrive while draining proceeds. (low confidence) [source]
- Read and write tickets govern concurrent admission to the storage engine; operations without a ticket queue. Tickets are not client connections or memory quotas, and no general fixed memory-per-ticket formula follows from the ticket count. (medium confidence) [source]
- Increasing ticket limits while CPU, disk, or cache is saturated can worsen queueing and eviction. During index-build incidents, correlate ticket waits with cache eviction, disk I/O, latency, and replication lag before changing concurrency; this diagnostic recommendation is an inference from the documented storage-engine behavior. (medium confidence) [source]
- SERVER-115329 describes index-build bulk-cursor memory growing with leaf-page count outside normal cache accounting, with possible OOM for very large indexes. Its proposed fallback to a non-bulk cursor is a proposal, not evidence of a shipped fix: the issue was resolved Won't Fix on September 15, 2026, with no fix version listed. (low confidence) (verified as of 2026-09-15) [source]
Children
- Application-thread eviction and dirty-cache pressure (frontier)
- Storage-engine ticket queues and dynamic admission (frontier)
- Index-build bulk-cursor memory accounting (frontier)
Frontier under this node: Application-thread eviction and dirty-cache pressure, Index-build bulk-cursor memory accounting, Storage-engine ticket queues and dynamic admission