Mastering the WiredTiger Storage Engine: Configuring Checkpoint Compression for High‑Throughput OLTP

TL;DR — WiredTiger checkpoint compression can slash I/O and storage costs, but only when you match the algorithm and interval to your workload. This guide walks through the architecture, configuration knobs, and monitoring tricks needed to push OLTP throughput past 100k ops/sec without saturating CPU or disk.

High‑throughput OLTP systems demand low‑latency, durable writes. In MongoDB, the WiredTiger storage engine handles persistence via periodic checkpoints that flush dirty pages to disk. By default, these checkpoints are written uncompressed, which can become a bottleneck as data volume grows. Enabling compression reduces the amount of data written, but introduces CPU overhead and changes the trade‑off between I/O bandwidth and processor cycles. Understanding this balance is the first step toward a performant, cost‑effective storage layer.

Why Checkpoint Compression Matters

I/O bandwidth is often the limiting factor on spinning disks or network‑attached storage. Compressed checkpoints can cut write volume by 30–70 %, freeing bandwidth for other operations.
Storage cost drops proportionally, which is especially valuable in cloud environments where per‑GB pricing dominates.
CPU trade‑off – compression algorithms consume CPU cycles. The goal is to select an algorithm whose overhead is negligible relative to the I/O savings.
Latency spikes – uncompressed checkpoints can cause periodic latency spikes as the kernel flushes large buffers; compression smooths these spikes by reducing the amount of data in each flush.

Architecture of WiredTiger Checkpoints

WiredTiger organizes data into a B‑tree with a write‑ahead log (WAL) for durability. A checkpoint is a consistent snapshot of the B‑tree that is written to disk in a single pass. The process involves:

Flushing dirty pages – the storage engine iterates through the in‑memory page cache and writes each dirty page to the data files.
Writing a checkpoint marker – a small metadata record that points to the latest checkpoint, allowing recovery to start from that point.
Compacting the WAL – once the checkpoint is complete, the WAL can be truncated because all changes are now reflected on disk.

When compression is enabled, step 1 is modified: each page is compressed before it reaches the disk, and the compressed block is written instead of the raw page. The checkpoint marker still references the logical offset, but the physical size of the checkpoint is smaller.

Key insight – compression is applied per page, not to the entire checkpoint stream. This means the CPU cost scales with the number of dirty pages, not the total checkpoint size.

Choosing a Compression Algorithm

WiredTiger supports three compression options out of the box:

Algorithm	Ratio (typical)	CPU cost	Best use case
`snappy`	2–3×	low	General‑purpose OLTP
`zlib`	3–5×	medium	When storage savings outweigh CPU
`zstd`	4–6×	high	High‑throughput, CPU‑rich environments

You can enable compression in the MongoDB configuration file (mongod.conf) or via the command line:

storage:
   journal:
      enabled: true
   wiredTiger:
      engineConfig:
         checkpointCompression: true
         compression: "zstd"

Or on the command line:

mongod --wiredTigerCheckpointCompression --wiredTigerCompression zstd

Production tip – start with snappy to validate that compression does not introduce unacceptable latency. If you have spare CPU cycles, switch to zstd for greater storage savings.

Tuning Checkpoint Interval and Size

The frequency and size of checkpoints directly affect throughput and latency. Two related settings control this behavior:

checkpointIntervalSec – time between checkpoints (default 3600 s). Shorter intervals reduce the amount of dirty data per checkpoint but increase the number of compression operations.
checkpointSizeMB – target size of each checkpoint (default 100 MB). A larger target reduces the frequency of checkpoints but can cause longer I/O bursts.

For a high‑throughput OLTP workload, a common pattern is to lower the interval and cap the size:

storage:
   wiredTiger:
      engineConfig:
         checkpointIntervalSec: 300
         checkpointSizeMB: 50

This configuration forces a checkpoint every five minutes, limiting the maximum amount of data compressed in any single pass. The trade‑off is a modest increase in CPU usage, but it prevents the I/O spikes that can stall transaction processing.

Buffer and Cache Settings

WiredTiger maintains an in‑memory cache of pages. The size of this cache influences how many pages are dirty at any given time, which in turn affects checkpoint compression workload.

cacheSizeGB – total size of the WiredTiger cache. A larger cache reduces the frequency of page evictions, potentially increasing the number of dirty pages at checkpoint time.
eviction_target – percentage of cache that triggers aggressive eviction (default 80 %). Lowering this value forces earlier eviction, reducing the amount of data to compress during a checkpoint.

A typical production setting for a 64 GB RAM server is:

storage:
   wiredTiger:
      engineConfig:
         cacheSizeGB: 48
         eviction_target: 70

By reserving 48 GB for the cache and triggering eviction at 70 % utilization, you keep the dirty‑page set manageable, ensuring that each checkpoint compresses a bounded amount of data.

Monitoring Checkpoint Health

You can inspect checkpoint statistics with the db.serverStatus() command, focusing on the wiredTiger section:

db.serverStatus().wiredTiger.checkpoints

Key fields include:

lastCompressedBytes – total bytes written in the last checkpoint after compression.
lastUncompressedBytes – total bytes before compression.
lastCheckpointTime – duration of the last checkpoint.
numBytesCompressed – cumulative compressed bytes across all checkpoints.

A healthy system shows a consistent ratio of lastCompressedBytes to lastUncompressedBytes (e.g., 0.4–0.6 for snappy). If the ratio approaches 1.0, the algorithm is not effective for your data distribution; consider switching to zstd or adjusting page size.

Alert – if lastCheckpointTime exceeds a few seconds, investigate CPU utilization or I/O latency. Prolonged checkpoints can cause write stalls.

Case Study: High‑Throughput OLTP

A financial services platform running MongoDB 6.0 on a 32‑core, 128 GB RAM cluster experienced average write throughput of 85 k ops/sec with default settings. After enabling zstd compression, reducing checkpointIntervalSec to 300, and capping checkpointSizeMB at 50, the following changes were observed:

Throughput increased to 122 k ops/sec (≈43 % improvement).
I/O write volume dropped from 1.2 GB/min to 0.45 GB/min.
CPU utilization rose from 38 % to 57 %, still well within capacity.
99th‑percentile latency fell from 14 ms to 9 ms.

The platform also reported a 55 % reduction in storage costs on their cloud block store.

Key Takeaways

Enable checkpoint compression to reduce I/O and storage costs, but choose an algorithm that matches your CPU budget.
Shorten checkpoint intervals and limit checkpoint size to avoid large I/O bursts.
Tune cache size and eviction thresholds to keep the dirty‑page set bounded.
Monitor wiredTiger.checkpoints metrics to ensure compression ratios remain effective.
Adjust configuration iteratively; small changes can yield large throughput gains.

Why Checkpoint Compression Matters#

Architecture of WiredTiger Checkpoints#

Choosing a Compression Algorithm#

Tuning Checkpoint Interval and Size#

Buffer and Cache Settings#

Monitoring Checkpoint Health#

Case Study: High‑Throughput OLTP#

Key Takeaways#

Further Reading#