<!-- llms-explorer concept facts · https://llms-explorer.com/tree/application-thread-eviction-and-cache-stalls/ · pack 2026-10-31 · ~1571 tokens -->

# Application-thread eviction and cache stalls

> Source-anchored research for Application-thread eviction and cache stalls. Run status: COMPLETED.

Parent: [WiredTiger cache eviction and dirty ratio](https://llms-explorer.com/tree/wiredtiger-cache-eviction-and-dirty-ratio/) · 4 facets · 15 facts · page: https://llms-explorer.com/tree/application-thread-eviction-and-cache-stalls/

## How it works

- The eviction target and trigger serve different roles: background workers operate above the target, whereas reaching the trigger recruits application threads. Dirty-content limits can also throttle application threads, so total cache occupancy below its overall trigger does not rule out foreground eviction. (high confidence) — [source](https://source.wiredtiger.com/mongodb-4.4/arch-eviction.html)
- The inspected MongoDB master README describes cache-pressure detection that combines exceeded triggers, lack of commit progress, and application eviction time; it describes aborting oldest transactions as remediation. These development-branch details do not establish availability or defaults in a released version. (low confidence) (verified as of 2026-10-30) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/storage/wiredtiger/README.md)
- The UBC researchers' 2018 study of WiredTiger performance diagnosis found that aggregate profiling was poorly suited to rare latency spikes. Their analysis supports examining per-thread timelines and time-correlated events when investigating foreground eviction stalls. (low confidence) — [source](https://www.cs.ubc.ca/~bestchai/papers/fse18-wiredtiger.pdf)

## Problems, failure modes and limitations

- When background eviction cannot keep pace and a configured eviction trigger is reached, WiredTiger can require application threads to perform eviction before they continue reading or writing, adding work to the request path and increasing latency. (high confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/storage/wiredtiger/README.md)
- A 2018 University of British Columbia study of WiredTiger performance investigations recorded cases where application latency rose when eviction was needed but no work was available. Eviction stalls need not correspond to a slow individual disk operation. (low confidence) — [source](https://www.cs.ubc.ca/~bestchai/papers/fse18-wiredtiger.pdf)
- A MongoDB 5.0.10 user reported application-thread eviction and simultaneous read/write latency spikes at approximately 80% cache usage and 1.4% dirty content. The thread did not establish the cause, so those snapshots cannot establish a universal threshold rule or a fix. (low confidence) — [source](https://www.mongodb.com/community/forums/t/why-is-mongodb-using-application-threads/234620)

## Comparisons and alternatives

- Keep a gap between the dirty eviction target and trigger: a historical WiredTiger maintainer explanation says making them equal delays background relief until operations face the hard limit. Treat the specific 2017 and 2020 tuning recipes as workload-era examples rather than general current settings. (medium confidence) — [source](https://groups.google.com/g/wiredtiger-users/c/zNVzB6ZrYt4/m/YHjzWb2ECQAJ)

## Facts and statements

- Clean eviction can discard an unchanged page directly, whereas dirty eviction reconciles modified content and writes it out. Dirty eviction can consequently add more work and I/O to an application operation. (high confidence) — [source](https://source.wiredtiger.com/mongodb-4.4/arch-eviction.html)
- For diagnosis, sample db.serverStatus().wiredTiger.cache['pages evicted by application threads'] repeatedly and correlate increases with latency and cache pressure over the same interval. This is a diagnostic inference from MongoDB monitoring guidance and the research emphasis on time-series evidence. (medium confidence) — [source](https://www.mongodb.com/docs/manual/troubleshooting/replication-lag.md)
- Adding eviction workers requires measurement: Percona reported insufficient workers in one bulk-load workload, while the UBC study documented a case where creating fewer additional workers reduced contention and improved throughput. More workers are not a universal cure. (medium confidence) — [source](https://www.percona.com/blog/tuning-mongodb-for-bulk-loads/)
- AceMQ describes an anonymous payments incident in which application-thread eviction coincided with multi-second write stalls and upstream pool saturation. The provider reports recovery after cache sizing and working-set changes, but supplies no dated incident timeline, MongoDB version, or raw measurements. (low confidence) — [source](https://acemq.com/use-cases/mongodb-wiredtiger-eviction-remediation/)
- WT-16790 reports a disaggregated-storage test hanging while a transaction operation waited in application-assisted eviction, with stack frames in __wti_evict_app_assist_worker and __wt_txn_commit. This is evidence for that test configuration, not proof that all production MongoDB releases share the fault. (low confidence) (verified as of 2026-09-30) — [source](https://jira.mongodb.org/browse/WT-16790?attachmentSortBy=dateTime)
- Clean-page eviction can discard an unchanged in-memory page; dirty-page eviction requires reconciliation. Consequently, page-eviction counts alone do not express the cost of eviction or how much storage work it entails. (medium confidence) — [source](https://source.wiredtiger.com/mongodb-4.4/arch-eviction.html)
- Eviction needs eligible pages and exclusive access to them. Application threads assisting eviction therefore do not guarantee that space will be freed promptly; blocked progress must be distinguished from merely doing more eviction work. (medium confidence) — [source](https://source.wiredtiger.com/mongodb-4.4/arch-eviction.html)
- Percona's bulk-load investigation demonstrated a workload-specific tuning experiment involving more eviction workers and a smaller cache with lower dirty thresholds. Treating those settings as a universal prescription is unwarranted: worker counts affect CPU and I/O demand, and the architecture guide describes dynamically balancing eviction performance against worker overhead. (medium confidence) — [source](https://www.percona.com/blog/tuning-mongodb-for-bulk-loads/)
