# Eviction thread sizing and wiredTigerEngineRuntimeConfig tuning > Source-anchored research for Eviction thread sizing and wiredTigerEngineRuntimeConfig tuning. Run status: COMPLETED. Parent: [WiredTiger cache eviction and dirty ratio](https://llms-explorer.com/tree/wiredtiger-cache-eviction-and-dirty-ratio/) · 5 facets · 19 facts · page: https://llms-explorer.com/tree/eviction-thread-sizing-and-wiredtigerengineruntimeconfig-tuning/ ## 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](https://jira.mongodb.org/browse/WT-18829) - 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](https://www.mongodb.com/docs/manual/reference/parameters/) - 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](https://groups.google.com/g/wiredtiger-users/c/zNVzB6ZrYt4/m/YHjzWb2ECQAJ) ## 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](https://www.percona.com/blog/tuning-mongodb-for-bulk-loads/) - 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](https://jira.mongodb.org/browse/WT-14601) - 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](https://www.percona.com/blog/tuning-mongodb-for-bulk-loads/) ## 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](https://source.wiredtiger.com/develop/tune_cache.html) - 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](https://www.percona.com/blog/tuning-mongodb-for-bulk-loads/) - 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](https://source.wiredtiger.com/develop/arch-eviction.html) ## 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](https://jira.mongodb.org/browse/WT-2898) - 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](https://www.mongodb.com/docs/manual/reference/parameters/) ## 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](https://www.percona.com/blog/tuning-mongodb-for-bulk-loads/) - 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](https://source.wiredtiger.com/develop/tune_cache.html) - 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](https://www.percona.com/blog/tuning-mongodb-for-bulk-loads/) - 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](https://raw.githubusercontent.com/mongodb/mongo/master/src/mongo/db/storage/wiredtiger/wiredtiger_global_options.idl) - 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](https://www.amperecomputing.com/tuning-guides/mongoDB-tuning-guide) - 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](https://jira.mongodb.org/browse/SERVER-28026) - 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](https://raw.githubusercontent.com/mongodb/mongo/master/src/mongo/db/storage/wiredtiger/wiredtiger_global_options.idl) - 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](https://www.percona.com/blog/tuning-mongodb-for-bulk-loads/)