Context
WiredTiger is designed to use cache, so a high occupancy percentage is not automatically a memory incident. Investigate eviction effort, dirty data, filesystem cache, query work, and the host's actual memory boundary. A larger internal cache can reduce useful memory elsewhere and leave the original workload problem intact.
Establish the deployment's memory boundary
Record MongoDB version, deployment model, available RAM or container limit, configured WiredTiger cache, process memory, and other services. Use the platform's supported diagnostics to confirm what memory limit the process recognizes.
MongoDB uses both WiredTiger's internal cache and the operating system's filesystem cache. Their contents and compression representations differ. Do not sum them as identical copies or assume the process should consume all host memory directly.
Review current vendor guidance before overriding automatic cache sizing. A fixed rule copied from another deployment can be unsuitable for a container, a shared host, or a different server version.
Read eviction and workload evidence together
Use authorized serverStatus cache statistics and the version's documented metric definitions. Record cache bytes, dirty-data behavior, pages read into cache, eviction activity, and evidence of application threads participating in eviction where supported.
Distinguish ordinary background eviction from pressure that delays useful work. Counters can grow during healthy operation. Interval rates, latency, and the workload timeline make them interpretable; a large lifetime total alone does not establish current overload.
Correlate storage latency, checkpoints, write volume, and application response time. A slow storage path can make dirty-data management more difficult, while an inefficient query can churn the cache. Both may appear as cache pressure but require different corrections.
Inspect query and index access patterns
Compare the affected query shapes with execution evidence. Excessive documents examined, unsuitable indexes, broad scans, and new aggregation behavior can expand the active working set. A larger cache may temporarily hide that work while growth continues.
Review indexes for actual utility and write cost. Adding an index consumes storage and cache and can increase write work. Select it through the measured query contract rather than creating every possible field combination.
Include batch jobs, analytics, backups, and a recovering replica in the workload timeline. Their access patterns can differ from the usual customer path. Confirm whether the performance problem is local to one member or shared across the replica set.
An illustrative misleading occupancy alert
A monitoring rule pages whenever internal cache occupancy is high. It fires during healthy steady traffic and is eventually ignored. Later, a new export query causes cache churn and increased storage reads, but operators see the same familiar alert.
The team replaces the occupancy-only interpretation with eviction, read, latency, and host-pressure evidence. It fixes the export's access pattern and validates the application. The resulting alert describes actionable pressure rather than normal use of a cache.
Quick diagnostic map
| Evidence | Interpretation to test | Next check |
|---|---|---|
| Cache nearly full; latency stable | Normal occupancy | Eviction and workload trend |
| Reads and eviction rise after query change | Working-set churn | Query shape and indexes |
| Dirty pressure follows slow storage | Flush bottleneck | Storage and checkpoint behavior |
| Process fits; host still under pressure | Incomplete memory budget | Filesystem cache and other consumers |
A focused operator exercise
Use a representative dataset and the production query mix in an isolated environment. Capture warmup, steady state, and the suspected batch overlap. Record cache-statistic definitions, host memory, storage latency, and correct query results.
Compare one query, index, or supported cache change at a time. Include writes and replica behavior where relevant. Verify application latency and useful completion rather than only occupancy. Rehearse restart and warmup so the accepted setting does not depend on an unrealistically preloaded cache.
Define an evidence-based operating response
Assign cache-pressure alerts to an owner who can inspect query behavior and storage as well as memory. Keep diagnostic privileges narrowly appropriate and avoid exporting sensitive documents merely to analyze a query shape.
Reevaluate the memory model after container-limit changes, host consolidation, or major upgrades. Preserve headroom for the operating system and supporting processes. A memory setting is an operating assumption that needs maintenance, not a one-time universal percentage.
Frequently asked questions
Is a full WiredTiger cache a leak?
Not by itself. Evaluate eviction, host pressure, workload changes, and application latency.
Should I allocate nearly all RAM to WiredTiger?
Follow current deployment-specific guidance and account for filesystem cache, other processes, and the actual memory limit. Test any override.
Continue the investigation
- MongoDB Compound Indexes: Match Field Order to the Queries Customers Actually Run
- MongoDB Oplog Windows: Plan for Outage and Catch-Up
Browse the cloud, server and infrastructure guide library for related operational questions.
Explore Clouvenix MongoDB Operations & Performance to discuss implementation, validation and operational handover.
Technical reference
FAQ: MongoDB Storage for Self-Managed Deployments - Database Manual - MongoDB Docs
Self-Managed Configuration File Options - Database Manual - MongoDB Docs