Eviction thread sizing and wiredTigerEngineRuntimeConfig tuning
Parent: WiredTiger cache eviction and dirty ratio · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-b7c969c2a118
↓ Facts as markdownall context files
Source-anchored research for Eviction thread sizing and wiredTigerEngineRuntimeConfig tuning. 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
- Before increasing workers, examine whether eviction can supply enough candidates. WT-18829 describes a high-data-handle customer workload in which candidate supply capped throughput and extra workers did not help. The issue uses FTDC but explicitly labels the per-tree dirty-content distribution as an inference because the needed per-collection statistics were absent. (low confidence) [source]
- The runtime configuration mechanism is db.adminCommand({setParameter:1,wiredTigerEngineRuntimeConfig:"eviction=(threads_min=4,threads_max=4)"}). The values illustrate syntax, not a tuning recommendation. MongoDB documents this parameter as runtime-only; startup persistence requires a separate startup configuration mechanism. (high confidence) [source]
- Do not set dirty eviction target equal to dirty eviction trigger: the maintainer explanation says this leaves almost no recovery margin after foreground work stalls. The architecture guide requires each target to remain below its corresponding trigger. (high confidence) [source]
Measurements and reference values
- Percona's 2020 bulk-load case changed several settings together: 20 eviction threads, lower dirty thresholds, and a WiredTiger cache whose size Percona recorded as 1 Gb. The case supports workload-specific experimentation; it does not isolate the benefit of thread count. More eviction work consumes I/O bandwidth and compression CPU. (low confidence) [source]
- More eviction threads can reduce throughput. WT-14601 reports this in a YCSB 100% update workload: extra workers increased page write-back and application threads waited more often for eviction to finish. This is a workload counterexample, not a universal scaling result. (low confidence) [source]
- In its May 2020 bulk-load case, Percona combined 20 fixed eviction threads, a WiredTiger cache recorded as 1 Gb, and dirty target/trigger values of 1%/5%. These simultaneous interventions do not isolate the benefit of thread count and should not be copied as a general production recipe. (low confidence) [source]
Problems, failure modes and limitations
- Eviction thread sizing controls background cache reclamation. If background workers cannot keep up and a trigger is reached, application threads assist with eviction, which can increase operation latency. Overall cache pressure and dirty-data pressure have separate target/trigger pairs. (high confidence) [source]
- Historical guidance must remain version-scoped: Percona's 2020 article and Ampere's MongoDB 6.0.3 guide describe an upper limit of 20 workers. The cached development configuration source instead permits 1–64 for both thread bounds; those older limits must not be presented as universal current limits. (high confidence) (verified as of 2026-10-21) [source]
- Overall cache occupancy alone cannot explain application-thread eviction. Dirty-content and update-content triggers also recruit application threads, so investigate those pressure dimensions before concluding that the background thread count is too small. (medium confidence) [source]
Comparisons and alternatives
- Treat thread count as a workload experiment rather than a universal constant: WT-2898 identifies workload, hardware and OS dependence, while Percona reports that additional workers consume I/O bandwidth and CPU for compression. Increasing workers requires spare resources. (high confidence) [source]
- MongoDB documentation advises changing wiredTigerEngineRuntimeConfig only under MongoDB engineer direction. A maintainer warned in 2017 that runtime eviction reconfiguration can disrupt throughput; Percona also observed client blocking during reconfiguration. Schedule and measure any approved change rather than assuming it is operationally free. (high confidence) [source]
Facts and statements
- Ampere's MongoDB tuning guide demonstrates a setParameter example for wiredTigerEngineRuntimeConfig using eviction=(threads_min=4,threads_max=8), while Percona's May 2020 bulk-load case describes the four-thread default and shows a 20/20 runtime command. These are distinct examples, not a shared recommendation; choose values for the workload and server version. (medium confidence) [source]
- WiredTiger allows eviction configuration at connection open and through WT_CONNECTION::reconfigure. MongoDB runtime recipes and startup configuration are separate mechanisms; a runtime setParameter example alone is not evidence that the change persists after restart. (high confidence) [source]
- For tuning verification, correlate cache occupancy and dirty bytes with application-thread eviction and operation latency. Percona used monitoring to diagnose checkpoint-related stalls; OneUptime illustrates inspecting serverStatus().wiredTiger.cache. A full cache by itself does not establish that additional workers will improve performance. (medium confidence) [source]
- The MongoDB master IDL snapshot exposes wiredTigerEvictionThreadsMin and wiredTigerEvictionThreadsMax at startup and runtime, each with default 4 and range 1–64. The embedded WiredTiger development API configuration instead defaults to minimum 1 and maximum 8. Distinguish MongoDB defaults from standalone engine defaults, and check the deployed release before using the newer named parameters. (high confidence) (verified as of 2026-10-20) [source]
- Ampere’s guide, updated 2024-11-05 and written around MongoDB 6.0.3, says thread bounds should match but demonstrates threads_min=4,threads_max=8. Its example is internally inconsistent with that advice and does not establish an optimal setting. (low confidence) [source]
- Historically, SERVER-28026 disabled adaptive eviction-thread sizing for MongoDB 3.2 and 3.4 by setting both bounds to four. The heuristic introduced by WT-2898 assumed a sufficiently large maximum and startup behavior representative of steady-state load; this history does not prove unequal bounds are always wrong today. (high confidence) [source]
- In the MongoDB master source snapshot retrieved on 2026-10-20, wiredTigerEvictionThreadsMin and wiredTigerEvictionThreadsMax both default to four, accept values from 1 through 64, and support startup/runtime updates. KV-engine callbacks translate updates into WiredTiger reconfigure strings. This is development-source evidence, not a guarantee for any released binary. (high confidence) (verified as of 2026-10-20) [source]
- For diagnosis, compare cache and dirty pressure, eviction work and foreground latency before and after a controlled tuning change. Percona used time-series metrics to identify dirty-page accumulation; WiredTiger recommends page-eviction statistics to assess cache behavior. A changed thread count alone is not evidence of improvement. (medium confidence) [source]
Children
- No children recorded.