WiredTiger Dirty Cache %, MongoDB

​

At a glance

The fraction of WiredTiger’s cache that holds modified (“dirty”) pages waiting to be written to disk by a checkpoint or eviction. Every write in MongoDB first lands in the in-memory cache and is marked dirty; the storage engine then flushes those pages to disk in the background. This gauge shows how much of the cache is currently dirty. A small dirty fraction is healthy and normal; a large one means writes are arriving faster than WiredTiger can flush them. The card turns red at >20% because once dirty content climbs past the engine’s eviction trigger, MongoDB starts forcing application threads to help evict, which stalls writes and spikes latency.

​

Calculation

dirty_cache_pct = cache."tracked dirty bytes in the cache"
                  / cache."maximum bytes configured"
                  x 100

• tracked dirty bytes in the cache is the volume of modified pages currently held in the cache that still need to be flushed to disk. Writes increase it; checkpoints and eviction decrease it.
• maximum bytes configured is the configured WiredTiger cache size (by default roughly 50% of RAM minus 1 GB, or 256 MB, whichever is larger). Using the configured maximum as the denominator, rather than the currently used bytes, gives a stable ceiling so the gauge is comparable over time.

• WiredTiger has its own internal dirty thresholds. By default the engine begins background eviction of dirty pages at roughly 5% dirty and starts forcing application threads to participate in eviction at roughly 20% dirty. The card’s >20% alert is aligned with that second threshold, the point where writes start paying an eviction tax.
• A high dirty fraction is a write-flush problem, not a write-volume problem in isolation. It rises when incoming write rate outpaces the engine’s ability to flush, which can be caused by slow disk, an oversized write burst, an infrequent checkpoint cadence, or contention from background eviction.
• Per-member. On a replica set the primary carries the write load and usually shows the highest dirty fraction; secondaries dirty their cache as they apply the oplog.

​

Worked example

Why it climbed:
  Incoming write rate (replay)  >  flush rate to disk
  Background eviction trigger   ~  5%  dirty  (engine starts flushing harder)
  App-thread eviction trigger   ~ 20%  dirty  (writes now pay the eviction tax)
  Conclusion: writes are arriving faster than the engine can persist them,
              so dirty content accumulates until app threads are conscripted
              into eviction, which is what stalls write latency.

1. Immediate: throttle or pause the bulk replay so the incoming write rate drops below the flush rate; the dirty fraction drains as checkpoints catch up, usually within a checkpoint interval or two (default checkpoints run roughly every 60 seconds).
2. Structural: if dirty pressure recurs under normal load, the flush path is the bottleneck. Move to faster disk (dirty cache is acutely sensitive to write IOPS and latency), increase cache size so there is more room to absorb bursts, or reshape the workload to spread writes rather than batching them into spikes.

1. Dirty cache is the write-side mirror of cache hit rate. WiredTiger Cache Hit Rate % tells you whether reads fit in memory; this card tells you whether writes can be flushed fast enough. Read them together to understand total cache pressure.
2. The 20% line maps to a real engine behaviour, not an arbitrary number. Below it, eviction is a quiet background activity; above it, your application’s own threads are forced to evict, which is exactly when users feel write latency. That is why it is a “fix it now” line.
3. Slow disk is the usual root cause. A dirty fraction that climbs under ordinary write load almost always points to the storage layer not keeping up. Check disk write latency and IOPS before assuming the workload is at fault.

​

Sibling cards to read alongside

​

Reconciling against the source

mongosh: db.serverStatus().wiredTiger.cache returns "tracked dirty bytes in the cache", "maximum bytes configured", "bytes currently in the cache", and the eviction counters. Divide tracked dirty bytes by the configured maximum to reproduce this gauge. mongostat: the dirty column shows the dirty-cache percentage directly, refreshed each interval, and the used column shows total cache usage; these are the quickest live confirmation. Atlas: the Metrics tab has a Cache Activity chart, and the Cache Dirty Bytes / cache-fill series track the same pressure this card reports. db.serverStatus().wiredTiger: the broader document exposes eviction counters (pages evicted by application threads vs background workers) that explain why a high dirty fraction is hurting latency.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre