# WiredTiger cache sizing and working-set fit > Source-anchored research for WiredTiger cache sizing and working-set fit. Run status: COMPLETED. Parent: [Read Offload via Caching and Precomputed Views ($merge/$out, Computed Pattern)](https://llms-explorer.com/tree/read-offload-via-caching-and-precomputed-views-merge-out-computed-pattern/) · 3 facets · 6 facts · page: https://llms-explorer.com/tree/wiredtiger-cache-sizing-and-working-set-fit/ ## How it works - WiredTiger stores uncompressed collection pages in its internal cache, while the OS filesystem cache can retain compressed database-file pages. A hot working set larger than the WiredTiger cache therefore does not cause a physical disk read on every cache miss when the needed page remains in filesystem cache, although it adds page-load and decompression cost; misses from both caches expose the workload to disk performance. (high confidence) — [source](https://www.mongodb.com/docs/manual/faq/diagnostics.md) - serverStatus.wiredTiger.cache exposes current and configured cache bytes, bytes read into cache, dirty bytes, and eviction counters. A sustained high Read into rate means WiredTiger is loading pages frequently, but it does not prove physical disk reads because the OS filesystem cache may serve those reads. Correlate cache and eviction counters with host cached and available memory and disk read metrics. (high confidence) — [source](https://www.mongodb.com/docs/manual/faq/diagnostics.md) - MongoDB's current WiredTiger README describes a pressure path where WiredTiger can recruit application threads to perform eviction after cache utilization reaches its trigger. Time spent by application threads evicting can delay operations, so cache pressure may raise latency even when OS caching reduces physical disk reads. (medium confidence) (verified as of 2026-10-21) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/storage/wiredtiger/README.md?plain=1) ## Measurements and reference values - The MongoDB manual snapshot verified on 2026-10-14 documents the default WiredTiger internal-cache size as the larger of 50% of (RAM minus 1 GB) or 0.256 GB. This setting limits the internal cache, not all mongod memory. The manual says to leave room for filesystem cache and other RAM consumers, to reduce the cache when multiple mongod instances share a host, and to avoid raising it above the default without a specific need. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/manual/faq/diagnostics.md) - The MongoDB manual currently gives the default WiredTiger internal cache as the greater of 50% of (RAM minus 1 GB) or 256 MB. That default assumes one mongod per machine. Container memory limits, multiple mongod processes, and other memory consumers require additional headroom; MongoDB advises against raising the internal cache above its default without a workload-specific need. (high confidence) (verified as of 2026-10-18) — [source](https://www.mongodb.com/docs/manual/core/wiredtiger/) ## Comparisons and alternatives - Diagnose cache fit with correlated trends rather than cache occupancy alone. MongoDB exposes current and maximum cache bytes, pages read into cache, dirty bytes, and pages evicted by application threads through serverStatus().wiredTiger.cache. Its WiredTiger integration notes that reaching an eviction trigger can recruit application threads, and Percona and IBM guidance pairs cache and eviction indicators with disk reads, page faults, swap, or disk latency when investigating pressure. (medium confidence) — [source](https://www.mongodb.com/docs/manual/faq/diagnostics.md)