WiredTiger checkpoints and dirty-page write cost
Parent: WiredTiger cache eviction and dirty ratio · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for WiredTiger checkpoints and dirty-page write cost. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Structure and components
- Dirty pages contain modified cached data that requires reconciliation. Both checkpointing and dirty-page eviction can cause writes; checkpoint cadence alone therefore does not describe all background data-file write activity. (medium confidence) [source]
How it works
- WT-18765 reports that update-heavy test workloads accumulated dirty history-store content during the history-store checkpoint pass, when eviction skipped dirty pages in the syncing tree. The issue reports dirty-cache overshoot above its configured trigger. This is evidence for a specific mechanism, not a universal overshoot rate or an established fix. (low confidence) (verified as of 2026-10-26) [source]
- Inference for shard-key evaluation: compare per-shard dirty-cache pressure, physical write activity, checkpoint duration, and latency at the same logical workload. Because reconciliation and eviction consume resources, reduced concentration may improve headroom, but these sources do not demonstrate that a better-balanced shard key reduces aggregate checkpoint bytes or infrastructure cost by a fixed amount. (medium confidence) [source]
- Keep each eviction target below its corresponding trigger. The architecture guide requires that ordering; a WiredTiger developer's historical forum explanation warns that equal dirty target and trigger values can stall operations without leaving useful room for background eviction. (medium confidence) [source]
- The dirty target and dirty trigger serve different roles: the target activates background eviction, whereas reaching the dirty trigger can throttle application threads and require them to perform eviction work. Treating both thresholds as checkpoint triggers confuses separate mechanisms. (medium confidence) [source]
- Cost-analysis inference: compare candidate shard layouts using sustained per-node dirty-page pressure, physical writes, and latency under representative update locality. Eviction pressure and buffering effectiveness provide a mechanism for different costs even at similar logical operation rates; these sources do not quantify savings from any particular shard key. (medium confidence) [source]
Measurements and reference values
- In the TurtleKV paper dated 2025-12-08, the WiredTiger random-insert experiment found little write-amplification improvement across approximately 16–500 MB of dirty-buffer allocation, with stronger reductions above that range. These are workload-specific experimental results, not production MongoDB sizing thresholds. (low confidence) [source]
Problems, failure modes and limitations
- If background eviction cannot keep up, application threads can perform eviction before continuing reads or writes. Dirty-cache pressure can therefore increase request latency through foreground work as well as through checkpoint activity. (medium confidence) [source]
Comparisons and alternatives
- In Percona's June 2020 benchmark, identified by the author as MongoDB 4.2.7, throughput fell from approximately 7,500 to 40 operations/second around checkpoints. After changing eviction settings it fell from approximately 6,700 to 1,250 instead. This is a historical workload-specific tradeoff: tuning reduced stalls but also lowered peak throughput, and does not establish a modern-version default recommendation. (low confidence) [source]
- Use time series rather than overall averages to assess checkpoint impact. The UBC researchers' WiredTiger performance-diagnosis study explains how averages conceal outliers; Percona demonstrates this with one-second checkpoint/throughput traces and separately recommends tracking dirty-cache and block-write activity. (medium confidence) [source]
- WiredTiger can trade dirty-buffer memory for write efficiency by retaining updates before flushing. Lower dirty occupancy is therefore not by itself proof of lower total write cost; the trade-off must include write amplification and application latency. (medium confidence) [source]
- The WiredTiger develop Page Deltas documentation retrieved on 2026-10-30 describes writing changed entries instead of full page images only for disaggregated layered row-store trees. It does not justify assuming that all MongoDB deployments support delta-only checkpoint writes; the architecture guide explicitly disclaims release-specific completeness. (low confidence) (verified as of 2026-10-30) [source]
Facts and statements
- Checkpoints provide a consistent recovery point in the data files; the journal preserves intervening modifications for recovery. The previous checkpoint remains usable until the new checkpoint is published through metadata. (medium confidence) [source]
- The MongoDB manual retrieved on 2026-10-30 describes a 60-second checkpoint interval. This is a configured cadence, not a guarantee that a checkpoint completes within 60 seconds. Percona also describes checkpoint backlogs under I/O bottlenecks. (medium confidence) (verified as of 2026-10-30) [source]
- Checkpoint reconciliation processes dirty pages and skips clean pages, including pages cleaned earlier by eviction. Dirty eviction itself reconciles modified pages, whereas clean eviction can discard the cached page without rewriting its data. (medium confidence) [source]
- Dirty-page write cost includes more than journal appends: the developer explanation describes copy-on-write data-file placement and per-table metadata synchronization; Percona also identifies CPU demand from compression during eviction. Both storage bandwidth and CPU capacity belong in checkpoint-cost diagnosis. (medium confidence) [source]
- The 2020 IBM Research study of WiredTiger and RocksDB distinguishes database-generated write amplification from SSD-internal write amplification. It shows that short tests, drive state, dataset size, and device technology can distort cost and throughput comparisons; its standalone-engine results do not establish a MongoDB deployment cost multiplier. (low confidence) [source]
Children
- Dirty versus clean eviction (frontier)
- Page reconciliation and compression cost (frontier)
- History-store checkpoint ordering (frontier)
- Checkpoint and latency observability (frontier)
- Dirty-page reconciliation and update locality (frontier)
- Checkpoint versus eviction observability (frontier)
- Database versus SSD write amplification (frontier)
Frontier under this node: Checkpoint and latency observability, Checkpoint versus eviction observability, Database versus SSD write amplification, Dirty versus clean eviction, Dirty-page reconciliation and update locality, History-store checkpoint ordering, Page reconciliation and compression cost