WiredTiger checkpoints and checkpoint duration
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 checkpoint duration. 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.
How it works
- Correlate increasing checkpoint time with disk I/O, swap activity, dirty-cache trends, and workload latency. Percona's dashboard documentation identifies growing write volume or insufficient disk performance as possible causes, and its bulk-load investigation observed throughput degradation during increasingly long checkpoints. (high confidence) [source]
How-to and procedures
- Use time-aligned checkpoint start/end, throughput and latency observations when diagnosing periodic slowdowns. The UBC study found that aggregate performance metrics conceal outliers; Percona's bulk-load investigation similarly used metric trends to identify checkpoint-associated degradation. (medium confidence) [source]
Measurements and reference values
- The SIGMOD 2020 paper Rethinking Logging, Checkpoints, and Recovery observed substantial checkpoint-related throughput variability in its WiredTiger 2.9.3 TPC-C experiments. It used 500 warehouses, 100 GB and 40 GB buffer pools, and disabled fsync. These are historical benchmark results, not measured bounds for current MongoDB checkpoint duration. (low confidence) [source]
Problems, failure modes and limitations
- Dirty percentage alone cannot establish that checkpoint work is small. WT-12798 gives an illustrative 300 GB cache at 5% dirty, representing 15 GB of dirty cache content; Percona likewise describes checkpoint pressure as dependent on both cache size and dirty content. Dirty cache bytes should not be equated directly with compressed physical bytes written. (medium confidence) [source]
Comparisons and alternatives
- Percona PMM 3 describes its checkpoint-time panel as a per-second average of a periodic event. A panel value therefore needs its aggregation interpreted before it is compared with the duration of an individual checkpoint. (low confidence) (verified as of 2026-10-29) [source]
Facts and statements
- A checkpoint provides a consistent recovery point. WiredTiger retains the previous valid checkpoint while building its replacement; MongoDB can recover from that checkpoint if the new checkpoint fails, then replay journaled changes. (high confidence) [source]
- MongoDB documents a 60-second checkpoint interval. This describes scheduling, not a promise that each checkpoint completes within 60 seconds: Percona's MongoDB 4.2 bulk-load investigation reported checkpoints growing from seconds to minutes. (high confidence) (verified as of 2026-10-30) [source]
- Checkpoint preparation can wait for eviction to reduce dirty cache content. The checkpoint then walks dirty pages, reconciles them, flushes files and publishes metadata; clean pages can be skipped. (medium confidence) [source]
- Checkpoint duration and dirty-cache volume should be investigated together with storage performance. Percona's bulk-load case observed checkpoints lengthening from seconds to minutes while throughput degraded; this is a workload example, not a universal duration threshold. (medium confidence) [source]
- The retrieved serverStatus reference distinguishes most recent, minimum, maximum and total checkpoint time, and separate scrub times for waiting on dirty-content reduction. Check the fields exposed by the deployed build before constructing a checkpoint-duration query. (low confidence) (verified as of 2026-10-30) [source]
- Checkpointing does not imply rewriting every cached page. The architecture guide says the tree walk reconciles dirty pages and skips clean pages, including pages already made clean by eviction. This scopes the older bulk-load article's shorthand that all dirty pages must be flushed every 60 seconds. (high confidence) [source]
- Before starting its checkpoint transaction, WiredTiger can use eviction to reduce dirty content and wait for a target ratio unless progress stops. WT-12798 reports that a modest dirty percentage can leave this assistance inactive despite substantial absolute dirty volume. (high confidence) [source]
- The develop architecture guide describes single-threaded checkpoints as the default and an optional checkpoint_threads setting for parallel reconciliation. This development documentation is not a release-specific guarantee for a deployed MongoDB binary. (low confidence) (verified as of 2026-10-28) [source]
Children
- No children recorded.