WiredTiger Storage Engine Internals

Parent: MongoDB Performance Troubleshooting · Published reference · snapshot 2026-09-08 · skill mongodb-expert/references/mongodb-wiredtiger-internals.md

↓ Facts as markdown all context files

WiredTiger has been MongoDB's default storage engine since 3.2 (replacing MMAPv1). It is a B-tree backed, MVCC, copy-on-write engine with document-level concurrency, configurable in-memory cache, bloc

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.

MongoDB WiredTiger Storage Engine Internals

WiredTiger has been MongoDB's default storage engine since 3.2 (replacing MMAPv1). It is a B-tree backed, MVCC, copy-on-write engine with document-level concurrency, configurable in-memory cache, block-level compression, and a write-ahead journal. Everything below the document model - durability, concurrency, compression, eviction, checkpoints - is WiredTiger. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#mongodb-wiredtiger-storage-engine-internals]
This skill is the deep internals reference. For surface-level performance triage, see mongodb-performance-troubleshooting. For diagnostic packaging, see atlas-diagnostics-expert. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#mongodb-wiredtiger-storage-engine-internals]

1. Architecture Overview

WiredTiger has a hybrid architecture optimized for multi-core CPUs and large memory: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#1-architecture-overview]

Three layers

In-memory cache - uncompressed B-tree pages. Working set lives here. Default size: max(0.5 × (RAM − 1 GiB), 256 MiB). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#three-layers]
Block manager - translates pages to/from disk, owns checksums, compression, encryption, free-list. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#three-layers]
OS filesystem cache - holds compressed data blocks. Often roughly the same size as the WT cache (uncompressed) because of compression ratios. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#three-layers]

File layout under `dbPath`

mongod exposes WiredTiger via a single WT_CONNECTION (per-process), holding one WT_CACHE struct and N WT_SESSION objects for application threads. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#file-layout-under-dbpath]

2.1 Default sizing

The cache size formula (since 3.4): max(0.5 × (RAM − 1 GiB), 256 MiB), capped at 10 000 GiB. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#21-default-sizing]
Override with one of (mutually exclusive): [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#21-default-sizing]
Or at the command line: --wiredTigerCacheSizeGB 32 / --wiredTigerCacheSizePct 60. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#21-default-sizing]
Containers and cgroups: WT's default sizing was historically based on host RAM. Always pin cacheSizeGB explicitly when running in a container with a memory limit, or you will OOM. Newer MongoDB versions detect cgroup limits in some configurations, but pinning is still safest. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#21-default-sizing]
Sizing rule of thumb (dedicated host): target ~50% of RAM for the WT cache and leave the rest for the OS filesystem cache plus mongod overhead (connections, plan cache, TCMalloc fragmentation). On shared hosts or multi-mongod deployments, reduce proportionally per instance. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#21-default-sizing]

2.2 What lives in the cache

Uncompressed B-tree pages for collections and indexes that were touched recently [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#22-what-lives-in-the-cache]
Dirty pages awaiting reconciliation [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#22-what-lives-in-the-cache]
Update structures (per-key linked lists of in-progress modifications) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#22-what-lives-in-the-cache]
The history store (recent MVCC versions) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#22-what-lives-in-the-cache]
WT session metadata, transaction structures [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#22-what-lives-in-the-cache]

2.3 Two caches at once

WiredTiger uses two memory tiers: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#23-two-caches-at-once]
A common rule of thumb: leave ~50% of RAM for the OS filesystem cache. Setting cacheSizeGB too high starves the OS cache, increasing disk reads after a page is evicted from WT but before being purged from the FS cache. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#23-two-caches-at-once]

3. Eviction (the hottest topic in production)

Eviction reclaims cache space by either dropping clean pages or reconciling dirty pages (writing them to the data file). Done well: invisible. Done poorly: the source of 80% of WiredTiger production pain. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#3-eviction-the-hottest-topic-in-production]

3.1 Eviction subsystem

One eviction server thread - walks the B-trees in fairness order, finds candidates [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#31-eviction-subsystem]
N eviction worker threads - pop pages from queues and actually evict them [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#31-eviction-subsystem]
Three queues: two ordinary + one urgent queue (priority queue) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#31-eviction-subsystem]

The server samples a portion of each B-tree, scores pages by access recency, takes the one-third oldest of evictable candidates, and pushes them onto the queues. This approximates an LRU policy - true LRU would be too expensive for a multi-million-page cache. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#31-eviction-subsystem]

The urgent queue holds pages flagged for forced eviction (sessions disabling eviction/splitting, large in-memory pages exceeding the maximum size, etc.). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#31-eviction-subsystem]

3.2 The four thresholds you must know

Additional thresholds (newer versions): [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#32-the-four-thresholds-you-must-know]
Invariant: target < trigger for every pair. The engine will refuse a config that violates this. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#32-the-four-thresholds-you-must-know]

3.3 Application thread eviction — the smoking gun

Normal mode: only background eviction workers do reconciliation. Pressure mode: when cache used ≥ eviction_trigger (or dirty ≥ eviction_dirty_trigger), application threads must perform eviction before they're allowed to do their own work. This shows up in serverStatus() as: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#33-application-thread-eviction-the-smoking-gun]
A non-zero value means writes are being throttled and latency is climbing. A persistent non-zero rate (per-second, derived from FTDC deltas) signals chronic under-sizing or under-threaded eviction. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#33-application-thread-eviction-the-smoking-gun]

3.4 Tuning eviction at runtime

Use wiredTigerEngineRuntimeConfig to change cache/eviction parameters without restart: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#34-tuning-eviction-at-runtime]
Persist in mongod.conf under setParameter: (not storage.wiredTiger): [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#34-tuning-eviction-at-runtime]
Gotcha: forum users have reported db.adminCommand with this parameter not taking effect on certain versions - verify with db.serverStatus().wiredTiger after applying, and prefer setting it in mongod.conf for sticky deployments. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#34-tuning-eviction-at-runtime]

3.5 Reconciliation (how dirty eviction actually works)

When a dirty page is evicted, WT performs reconciliation: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#35-reconciliation-how-dirty-eviction-actually-works]
- Walk the in-memory page, collect committed values (newest visible to all readers) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#35-reconciliation-how-dirty-eviction-actually-works]
- Build a new on-disk image with one entry per key (newest committed value) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#35-reconciliation-how-dirty-eviction-actually-works]
- Push older committed versions to the history store (WiredTigerHS.wt) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#35-reconciliation-how-dirty-eviction-actually-works]
- If the resulting image exceeds the configured max page size, split into multiple pages [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#35-reconciliation-how-dirty-eviction-actually-works]
- Compress, checksum, write via the block manager [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#35-reconciliation-how-dirty-eviction-actually-works]
- If page is small enough to merge with a neighbor on the next pass, leave a hint [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#35-reconciliation-how-dirty-eviction-actually-works]
Reconciliation is the single most CPU-expensive operation in the engine. It's why: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#35-reconciliation-how-dirty-eviction-actually-works]
- Hot pages with massive update lists pin the cache [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#35-reconciliation-how-dirty-eviction-actually-works]
- Long-running transactions inflate the history store [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#35-reconciliation-how-dirty-eviction-actually-works]
- Cache pressure under heavy write workloads is fundamentally a reconciliation throughput problem [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#35-reconciliation-how-dirty-eviction-actually-works]

4. Checkpoint and Journal — Two Durability Mechanisms

WiredTiger combines checkpoints (point-in-time consistent snapshots flushed to disk) and a write-ahead log (the journal). Recovery uses both. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#4-checkpoint-and-journal-two-durability-mechanisms]

4.1 Checkpoint

Default interval: 60 seconds (storage.syncPeriodSecs, or via wiredTigerEngineRuntimeConfig as checkpoint=(wait=60)) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#41-checkpoint]
Alternative trigger: 2 GiB of journal accumulated since last checkpoint [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#41-checkpoint]
The checkpoint thread creates a consistent snapshot of all B-trees, writes new on-disk root pointers, and only after successful write does it consider the checkpoint complete [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#41-checkpoint]
Crash mid-checkpoint: the previous checkpoint stays valid; the new one is discarded [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#41-checkpoint]
Storage is copy-on-write: new pages are written to free space, then the root pointer is flipped - the old pages become free list candidates after the checkpoint completes [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#41-checkpoint]

4.2 Journal (write-ahead log)

Compressed with snappy by default. Configure via: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#42-journal-write-ahead-log]
Files are pre-allocated 100 MB segments named WiredTigerLog.<n> under dbPath/journal/ [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#42-journal-write-ahead-log]
Records ≤ 128 bytes are not compressed (minimum log record size) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#42-journal-write-ahead-log]
Default flush cadence: every 100 ms (group commit) - this is your data loss window in a crash [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#42-journal-write-ahead-log]
j: true write concern forces an immediate journal flush before acknowledging [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#42-journal-write-ahead-log]
disableJournal=true (NOT for replica-set members) skips the journal entirely [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#42-journal-write-ahead-log]

4.3 Recovery

Find the latest valid checkpoint in WiredTiger.wt [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#43-recovery]
Replay journal records from the checkpoint LSN forward [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#43-recovery]
For each table, resolve outstanding transactions (commit or roll back per stable timestamp) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#43-recovery]
Open WT_CONNECTION, expose to mongod [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#43-recovery]

Worst case data loss in a clean crash (no replica set): up to 100 ms of acknowledged writes from non-j:true clients. With j:true, zero. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#43-recovery]

4.4 Group commit and syncdelay

WiredTiger batches journal flushes via group commit. --syncdelay (or storage.syncPeriodSecs) controls the checkpoint cadence, not the journal flush. Many older blog posts conflate the two - be precise: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#44-group-commit-and-syncdelay]
- syncPeriodSecs (default 60) → checkpoint interval [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#44-group-commit-and-syncdelay]
- Journal flush → every 100 ms (hard-coded, plus j:true triggers) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#44-group-commit-and-syncdelay]

5. MVCC, Timestamps, and the History Store

MongoDB layered timestamp-based MVCC on top of WiredTiger's transaction subsystem to support snapshot isolation, causal consistency, and readConcern: "snapshot". [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#5-mvcc-timestamps-and-the-history-store]

5.1 Snapshot isolation

Every operation acquires a read snapshot at start. WT guarantees that the operation sees a consistent point-in-time view, regardless of concurrent writes. Readers never block writers; writers never block readers. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#51-snapshot-isolation]

5.2 Timestamp APIs

WT exposes a small set of global timestamps: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#52-timestamp-apis]
The pinned timestamp is the crucial concept: even if MongoDB advances oldest_timestamp, an active long-running snapshot pins the floor and forces WT to keep history. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#52-timestamp-apis]

5.3 The history store (WiredTigerHS.wt)

Introduced in 4.4 (replacing the old lookaside file). When reconciliation evicts a page with non-current committed versions, those older values spill into the history store. The current value stays in the data file. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#53-the-history-store-wiredtigerhswt]
History store key format: (table_id, record_id, start_timestamp, counter) - i.e., one entry per old version, per key, per timestamp. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#53-the-history-store-wiredtigerhswt]
The history store is itself a B-tree, lives in the cache, gets reconciled and evicted like any other table. Pages become reclaimable when all rows on the page are obsolete (no reader can see them, all are older than the pinned timestamp). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#53-the-history-store-wiredtigerhswt]

5.4 Long-running transactions — the cardinal sin

A snapshot pinned by a long transaction stalls cleanup: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#54-long-running-transactions-the-cardinal-sin]
- All updates in the transaction's view must remain available → history store grows [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#54-long-running-transactions-the-cardinal-sin]
- All in-progress updates accumulate in update lists → cache pressure [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#54-long-running-transactions-the-cardinal-sin]
- Reconciliation can't compress update lists into a single value [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#54-long-running-transactions-the-cardinal-sin]
- Keep transactions short (MongoDB aborts multi-doc transactions after 60 s by default, controlled by transactionLifetimeLimitSeconds) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#54-long-running-transactions-the-cardinal-sin]
- Set minSnapshotHistoryWindowInSeconds (default 300 s) sensibly - every second held forces history retention [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#54-long-running-transactions-the-cardinal-sin]
- Watch cache.history store on-disk size, cache.history store table updates inserted into history store, and transaction.read timestamp of the oldest active reader in FTDC [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#54-long-running-transactions-the-cardinal-sin]
- Don't run mongodump against a hot collection with a low snapshotHistoryWindow - it pins the snapshot [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#54-long-running-transactions-the-cardinal-sin]

6. Compression

Three knobs, three layers. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#6-compression]

6.1 Block compression (collection data)

Regular collections: snappy [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#61-block-compression-collection-data]
Time-series collections (5.0+): zstd [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#61-block-compression-collection-data]

Per-collection override at creation: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#61-block-compression-collection-data]

6.2 Prefix compression (indexes only)

Indexes use prefix compression: shared key prefixes are stored once. This is on by default and almost never worth turning off - it both saves space and speeds up scans (more keys per page). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#62-prefix-compression-indexes-only]

6.3 Journal compression

Records ≤ 128 bytes skip compression regardless. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#63-journal-compression]

7. Block Manager and Page Sizing

The block manager owns the on-disk layout. Pages are the unit of I/O. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#7-block-manager-and-page-sizing]

7.1 Default page sizes

Larger pages → better compression ratio (more data per block), worse cache granularity. Smaller pages → vice versa. MongoDB ships sensible defaults; touch only with profiling evidence. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#71-default-page-sizes]

7.2 In-memory page splits

When an application thread is updating a hot page and the in-memory size crosses memory_page_max, the thread is conscripted to forcefully split the page so reconciliation doesn't see an unbounded image. This shows up as elevated cache.pages split during eviction. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#72-in-memory-page-splits]

7.3 The free list

When pages are written via copy-on-write, old extents become free-list candidates. The block manager tracks these for reuse. Periodic compaction (db.runCommand({ compact: "<coll>" })) consolidates free space - useful after big deletes, mostly irrelevant during steady-state operation. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#73-the-free-list]

8. Read/Write Tickets and Concurrency

WT enforces a hard cap on concurrent storage-engine transactions: read tickets and write tickets. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#8-readwrite-tickets-and-concurrency]

8.1 Pre-7.0 behavior

128 read tickets, 128 write tickets, per-node, fixed [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#81-pre-70-behavior]
Configurable via storageEngineConcurrentReadTransactions and storageEngineConcurrentWriteTransactions [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#81-pre-70-behavior]
Exhaustion: new operations queue, latency climbs [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#81-pre-70-behavior]
db.serverStatus().wiredTiger.concurrentTransactions.{read,write}.available shows current free tickets [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#81-pre-70-behavior]

8.2 7.0+ dynamic ticketing

MongoDB 7.0 introduced a dynamic algorithm that adjusts ticket counts based on observed throughput and contention. Defaults are lower than 128 during normal operation - this is intentional. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#82-70-dynamic-ticketing]
Manually setting storageEngineConcurrentReadTransactions or storageEngineConcurrentWriteTransactions (or the older aliases wiredTigerConcurrentReadTransactions / wiredTigerConcurrentWriteTransactions) to a non-default value disables the dynamic algorithm on 7.0+. Don't override unless you have hard evidence of ticket starvation. Look at queue depth (queues.execution.*.in) not at available alone. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#82-70-dynamic-ticketing]

8.3 Document-level locking

WT uses optimistic concurrency control. Multiple writers can hit different documents simultaneously. Same-document concurrent writes → one wins, the other gets WT_ROLLBACK and MongoDB retries transparently. This is per-document, not per-collection - a fundamental advantage over MMAPv1's collection-level lock. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#83-document-level-locking]

9. In-Memory Storage Engine (Enterprise)

MongoDB Enterprise ships an alternative WT configuration with no disk persistence. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#9-in-memory-storage-engine-enterprise]

9.1 Configuration

Data lives only in memory. No data files, no journal, no checkpoint. Restart = empty database. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#91-configuration]

9.2 Use cases

Cache layer in front of a primary store [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#92-use-cases]
Real-time analytics with TTL'd ephemeral data [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#92-use-cases]
Test/CI environments that need MongoDB but not persistence [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#92-use-cases]

9.3 Trade-offs

Same MVCC, document concurrency, indexes, aggregation as on-disk WT [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#93-trade-offs]
Sustains higher write throughput (no journal/checkpoint cost) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#93-trade-offs]
Can act as a replica-set secondary alongside on-disk primaries - but every secondary needs enough RAM [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#93-trade-offs]
WT_CACHE_FULL errors are explicit and abort the operation (vs. on-disk where they'd just throttle) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#93-trade-offs]

10. Encryption at Rest

MongoDB Enterprise integrates encryption-at-rest at the WT block manager layer. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#10-encryption-at-rest]

10.1 Cipher

Default: AES-256-CBC via OpenSSL [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#101-cipher]
Linux only: also supports AES-256-GCM (authenticated encryption - strongly preferred) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#101-cipher]
The cipher is applied per-page after compression but before disk write [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#101-cipher]

10.2 Key management

Two options for the master key: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#102-key-management]
- KMIP: integration with an external KMIP-compliant appliance (HashiCorp Vault Enterprise, Thales CipherTrust, Fortanix, etc.) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#102-key-management]
  - Default protocol version 1.2; configurable to 1.0/1.1 with security.kmip.useLegacyProtocol: true [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#102-key-management]
- Local keyfile: read from a file on disk (test/dev only) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#102-key-management]
The master key encrypts per-database keys (DEKs). DEKs are stored in WiredTiger.wt and encrypted with the master key. Master-key rotation re-wraps DEKs without re-encrypting data. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#102-key-management]

10.3 Atlas behavior

Atlas always uses encryption-at-rest; cloud-provider key (CMK) integration via AWS KMS, Azure Key Vault, GCP KMS is available at the cluster level - that's BYOK over the same WiredTiger layer. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#103-atlas-behavior]

11.2 FTDC — the post-incident truth source

FTDC writes to dbPath/diagnostic.data/ at ~1 Hz: hundreds of metrics, ~1 MiB/hour, < 1% CPU overhead. Every metric above is captured here as a time series. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#112-ftdc-the-post-incident-truth-source]
- mongo-ftdc - Grafana-fed dashboards [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#112-ftdc-the-post-incident-truth-source]
- keyhole (Percona) - Go CLI parser, prints WT cache/eviction/checkpoint summaries [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#112-ftdc-the-post-incident-truth-source]
- tsdiag (MongoDB internal) - bundles FTDC + logs + serverStatus for support cases [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#112-ftdc-the-post-incident-truth-source]
Key derived metrics to compute from FTDC deltas: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#112-ftdc-the-post-incident-truth-source]
- pages evicted by application threads / second → throttling rate [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#112-ftdc-the-post-incident-truth-source]
- history store table on-disk size slope → long-txn pressure [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#112-ftdc-the-post-incident-truth-source]
- cache.bytes currently in the cache / maximum bytes configured → cache used % [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#112-ftdc-the-post-incident-truth-source]
- tracked dirty bytes / maximum bytes configured → dirty % [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#112-ftdc-the-post-incident-truth-source]

11.3 Verbose component logging

For deep-dive investigation, enable WT-component log verbosity in mongod.conf: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#113-verbose-component-logging]
This bloats logs fast - turn off when done. Diagnostic categories: WTCHKPT (checkpoint), WTEVICT (eviction), WTHS (history store), WTRECOV (recovery), WTRTS (rollback-to-stable), WTCMPCT (compaction). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#113-verbose-component-logging]

11.4 wt CLI tool

The WT distribution ships a wt command that opens a .wt file directly. Useful in disaster recovery and Percona-style forensics. Not in the mongod binary - you build it from the WT source tree. Common commands: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#114-wt-cli-tool]

12. Practical Tunables (the short list)

Raw WT config string passthrough (for parameters MongoDB doesn't expose directly): [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#12-practical-tunables-the-short-list]

13.1 Cache sizing

Estimate working set - the set of pages touched in a typical hour. Often << total data. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#131-cache-sizing]
Target: WT cache ≥ working set, with 20% headroom. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#131-cache-sizing]
Leave ~50% of RAM for OS filesystem cache. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#131-cache-sizing]
On containers, pin cacheSizeGB to a value that respects the cgroup limit. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#131-cache-sizing]
Don't blindly set cacheSizePct: 80 - that leaves nothing for the rest of mongod (connections, plan cache, query operators, TCMalloc fragmentation) and nothing for the kernel. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#131-cache-sizing]

13.4 Switching the journal compressor to zstd

Takes effect on next mongod restart. Pre-existing journal files keep their original compressor until they roll over (every ~100 MB or at checkpoint boundaries). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#134-switching-the-journal-compressor-to-zstd]

15.1 "Cache full" / WT_CACHE_FULL

Symptoms: WT_CACHE_FULL in mongod log; high latency; ops timing out. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#151-cache-full-wt_cache_full]
Action ladder (cheap → expensive): [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#151-cache-full-wt_cache_full]
- Increase eviction.threads_min/max [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#151-cache-full-wt_cache_full]
- Lower eviction_target from 80 to 75 (start evicting sooner) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#151-cache-full-wt_cache_full]
- Increase cacheSizeGB if there's RAM headroom [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#151-cache-full-wt_cache_full]
- Audit indexes - fewer indexes = fewer dirty pages on write [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#151-cache-full-wt_cache_full]
- Audit long transactions - kill any pinning history [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#151-cache-full-wt_cache_full]
- Move to a larger Atlas tier or instance type [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#151-cache-full-wt_cache_full]

15.2 Persistent dirty % above 20%

Cause: reconciliation can't keep up. Either disk write throughput is the bottleneck, or update lists are pinned by long transactions. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#152-persistent-dirty-above-20]
- Increase eviction threads [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#152-persistent-dirty-above-20]
- Verify disk IOPS / throughput against tier [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#152-persistent-dirty-above-20]
- Kill long transactions or readers [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#152-persistent-dirty-above-20]
- Move to provisioned IOPS storage [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#152-persistent-dirty-above-20]

15.3 History store growing unbounded

Symptom: WiredTigerHS.wt file size growing; cache.history store on-disk size climbing. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#153-history-store-growing-unbounded]
Cause: oldest active reader is pinned far in the past. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#153-history-store-growing-unbounded]
Action: kill the offending reader, lower minSnapshotHistoryWindowInSeconds if appropriate, audit long-running aggregations, mongodumps, and change-stream consumers. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#153-history-store-growing-unbounded]

15.4 Read/write ticket starvation

Pre-7.0 symptom: wiredTiger.concurrentTransactions.read.available → 0 sustained. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#154-readwrite-ticket-starvation]
7.0+ symptom: queues.execution.read.in > 0 sustained (queue depth, not available count). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#154-readwrite-ticket-starvation]
- Speed up the operations holding tickets (slow queries / locked writes) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#154-readwrite-ticket-starvation]
- Profile with db.currentOp({ active:true, secs_running:{$gt:1} }) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#154-readwrite-ticket-starvation]
- Do not raise ticket count blindly - it disables the dynamic algorithm and often makes throughput worse [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#154-readwrite-ticket-starvation]

15.5 Slow startup / recovery

Cause: checkpoint was old, journal is large, recovery must replay a lot. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#155-slow-startup-recovery]
Investigation: look at the WT recovery message at startup - it prints how many records were replayed. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#155-slow-startup-recovery]
- Lower syncPeriodSecs to make checkpoints more frequent [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#155-slow-startup-recovery]
- Pre-warm the cache on an upgraded node before serving traffic (see mongodb-upgrade-paths cookie pre-warm SOP) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#155-slow-startup-recovery]

15.6 Cold-cache after restart / failover

Symptom: latency spike, query queue blowup, replica catch-up slow. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#156-cold-cache-after-restart-failover]
Cause: Working set has to be re-read from disk. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#156-cold-cache-after-restart-failover]
- Pre-warm via touch/find on hot collections in a scripted warm-up [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#156-cold-cache-after-restart-failover]
- Use Atlas pre-warmed disks (newer tiers cache more of the working set) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#156-cold-cache-after-restart-failover]
- Don't restart all nodes at once [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#156-cold-cache-after-restart-failover]

15.7 Corruption: validate, repair, and forensics

WiredTiger pages are checksummed (CRC32C by default); the block manager will reject a torn page on read with WT_ERROR. Symptoms: corrupt WT page, checksum mismatch, WT_PANIC, or mongod refusing to start. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#157-corruption-validate-repair-and-forensics]
Triage path (in order of escalating risk): [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#157-corruption-validate-repair-and-forensics]
- Stop the node if it's still up - further writes can amplify damage [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#157-corruption-validate-repair-and-forensics]
- Run db.collection.validate({ full: true }) on a healthy replica to confirm the issue is local to the affected node [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#157-corruption-validate-repair-and-forensics]
- Re-sync from a healthy replica (initial sync) - the safest path for a single-node corruption in a replica set [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#157-corruption-validate-repair-and-forensics]
- --repair: mongod --repair --dbpath <dbPath> - last-resort rewrite that drops any unrecoverable data. Always back up dbPath/ before running. Repair does not preserve replica-set membership; the node must be re-added afterward. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#157-corruption-validate-repair-and-forensics]
- wt verify: low-level forensic check on individual .wt files using the standalone WT CLI tool (built from the WT source tree) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#157-corruption-validate-repair-and-forensics]
WT_PANIC is unrecoverable in-process. The node has to be restarted; if it panics again on startup, treat it as data-file corruption and follow the path above. Never run --repair on a node still serving traffic. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#157-corruption-validate-repair-and-forensics]

15.8 Index builds inflating the cache

Background index builds (post-4.2) hold uncommitted entries in the WiredTiger cache until commit. Symptoms during a build: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#158-index-builds-inflating-the-cache]
- Cache used % climbs and stays high [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#158-index-builds-inflating-the-cache]
- serverStatus().wiredTiger.cache["bytes belonging to the cache overhead"] grows [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#158-index-builds-inflating-the-cache]
- Throttle with maxIndexBuildMemoryUsageMegabytes (default 200 MB per build) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#158-index-builds-inflating-the-cache]
- Schedule large index builds in low-traffic windows [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#158-index-builds-inflating-the-cache]
- For very large collections, consider rolling index builds across replica-set members [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#158-index-builds-inflating-the-cache]

17. Related Skills

mongodb-performance-troubleshooting - surface-level triage; this skill is the deep dive [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#17-related-skills]
mongodb-capacity-planning - uses WT cache sizing formulas [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#17-related-skills]
mongodb-monitoring-observability - FTDC parsing, Atlas metrics [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#17-related-skills]
atlas-diagnostics-expert - Atlas live-diagnostics and diagnostic packaging [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#17-related-skills]
mongodb-upgrade-paths - references cache pre-warm SOP (Cookie 7.0→8.0 lesson) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#17-related-skills]
mongodb-transactions - multi-doc transaction layer above WT [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#17-related-skills]
mongodb-encryption - CSFLE/QE complement to WT encryption-at-rest [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#17-related-skills]
mongodb-indexes-deep - prefix compression interaction with index design [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#17-related-skills]
mongodb-time-series - bucket columnar layout sits on WT zstd default [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#17-related-skills]
mongodb-backup-restore - checkpoint/journal interaction with backup snapshots [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#17-related-skills]
mongodb-disaster-recovery - --repair workflow, validate(), and forensic recovery from data-file corruption [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#17-related-skills]

18. References

Primary documentation: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#18-references]
- MongoDB Manual - WiredTiger Storage Engine: <https://www.mongodb.com/docs/manual/core/wiredtiger/> [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#18-references]
- MongoDB Manual v8.2 - WiredTiger Storage Engine: <https://www.mongodb.com/docs/v8.2/core/wiredtiger/> [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#18-references]
- WiredTiger Source - Eviction Architecture: <https://source.wiredtiger.com/develop/arch-eviction.html> [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#18-references]
- WiredTiger Source - Cache Architecture: <https://source.wiredtiger.com/develop/arch-cache.html> [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#18-references]
- WiredTiger Source - History Store: <https://source.wiredtiger.com/11.0.0/arch-hs.html> [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#18-references]
- WiredTiger Source - Transactions: <https://source.wiredtiger.com/develop/arch-transaction.html> [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#18-references]
- WiredTiger Source - Timestamps: <https://source.wiredtiger.com/develop/arch-timestamp.html> [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#18-references]
- WiredTiger Source - Commit-level Durability Tuning: <https://source.wiredtiger.com/develop/tune_durability.html> [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#18-references]
- WiredTiger Source - Debugging: <https://source.wiredtiger.com/develop/debugging.html> [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#18-references]
- WiredTiger Source - Cache and Eviction Tuning (6.0): <https://source.wiredtiger.com/mongodb-6.0/tune_cache.html> [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#18-references]
- MongoDB Engineering - 8.0 Performance Improvements: <https://www.mongodb.com/company/blog/mongodb-8-0-improving-performance-avoiding-regressions> [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#18-references]
- Foojay / MongoDB - Inside the Engine: 8.0 Performance Relay: <https://foojay.io/today/inside-the-engine-the-sub-millisecond-performance-relay-of-mongodb-8-0/> [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#18-references]
- Percona - WiredTiger Logging and Checkpoint Mechanism: <https://www.percona.com/blog/wiredtiger-logging-and-checkpoint-mechanism/> [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#18-references]
- Percona - Compression Methods: Snappy vs. Zstd: <https://www.percona.com/blog/compression-methods-in-mongodb-snappy-vs-zstd/> [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#18-references]
- Percona - MongoDB 101: Tuning WiredTiger Cache: <https://www.percona.com/blog/mongodb-101-how-to-tune-your-mongodb-configuration-after-upgrading-to-more-memory/> [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#18-references]
- Datadog - Monitoring WiredTiger Performance Metrics: <https://www.datadoghq.com/blog/monitoring-mongodb-performance-metrics-wiredtiger/> [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#18-references]
- Mydbops - MongoDB 7.0 Dynamic WiredTiger Tickets: <https://www.mydbops.com/blog/mongodb-7-wiredtiger-tickets> [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#18-references]
- MongoDB Dev.to - Durable History Store (WiredTigerHS.wt): <https://dev.to/mongodb/mongodb-mvcc-durable-history-store-wiredtigerhswt-mn2> [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#18-references]
- WiredTiger Wiki - Reconciliation Overview: <https://github.com/wiredtiger/wiredtiger/wiki/Reconciliation-overview> [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#18-references]
- MongoDB Repo - WT Storage Engine README: <https://github.com/mongodb/mongo/blob/master/src/mongo/db/storage/wiredtiger/README.md> [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-wiredtiger-internals/#18-references]

Where this helps

Diagnosing WT_CACHE_FULL errors, high write latency, or timed-out operations on a MongoDB deployment under sustained write load. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Investigating why a WiredTigerHS.wt history-store file keeps growing unbounded on a cluster with long-running readers or aggregations. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Deciding how to size cacheSizeGB and eviction thresholds for a memory-constrained or high-throughput MongoDB deployment. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Root-causing persistent dirty-cache-percentage alerts or read/write ticket starvation during a performance-troubleshooting escalation. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Project ideas

Build an FTDC-based dashboard that tracks cache.history store on-disk size, eviction thresholds, and dirty percentage together to catch cache pressure before WT_CACHE_FULL hits. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Write a diagnostic script using db.currentOp({active:true, secs_running:{$gt:1}}) to catch long-running operations that are pinning the WiredTiger snapshot before they cause history-store bloat. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Prototype an eviction-tuning runbook that follows the cheap-to-expensive action ladder: raise eviction threads, lower eviction_target, increase cacheSizeGB, audit indexes and transactions, upsize the tier. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Build alerting on transactionLifetimeLimitSeconds and minSnapshotHistoryWindowInSeconds thresholds to catch long transactions before they stall cleanup. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Antipatterns

Running mongodump against a hot collection with a low snapshotHistoryWindow, which pins the snapshot and drives unbounded history-store growth. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Raising the read/write ticket count blindly in response to ticket starvation instead of profiling and fixing the slow operations holding tickets — this disables the dynamic algorithm and often makes throughput worse. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Letting multi-document transactions run long instead of keeping them short — MongoDB aborts them after 60 seconds by default (transactionLifetimeLimitSeconds), but damage to cache pressure accrues well before that abort. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Treating a persistent dirty-percentage alert as purely a disk-throughput problem without also checking whether long-running readers are pinning update lists that reconciliation can't compress. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Known issues

Eviction is responsible for a large share of WiredTiger production pain according to this pack's own account, and the tuning surface — four thresholds plus an application-thread eviction fallback — is intricate enough that misconfiguration is common. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
The four eviction thresholds carry a strict invariant (target < trigger for every pair) that the engine enforces, so tuning them requires understanding the relationships, not just raising individual numbers. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
History-store growth is a symptom with multiple possible root causes — long readers, long transactions, a low snapshot window — so the on-disk size metric alone doesn't point directly at the fix. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Ticket-starvation symptoms differ between pre-7.0 (available count hits zero) and 7.0+ (queue depth rises instead), so a runbook written against one version's metrics can silently stop working after an upgrade. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Children

Cache Architecture
Eviction (clean/dirty targets and triggers)
Application Thread Eviction
Reconciliation and Page Splitting (frontier, viability 3.02 / 5, below research gate)
Checkpoint Mechanism
Journal (Write-Ahead Log) (frontier, viability 3.83 / 5)
MVCC and Snapshot Isolation (frontier, viability 3.67 / 5)
History Store (WiredTigerHS.wt)
Timestamp APIs (oldest/stable/pinned) (frontier, viability 3.50 / 5)
Block Compression (snappy/zlib/zstd)
Block Manager and Page Sizing
Read/Write Tickets and Dynamic Concurrency (7.0+)
In-Memory Storage Engine (Enterprise)
Encryption at Rest (KMIP, AES-256-CBC/GCM)
Diagnostic Surface (serverStatus, FTDC, verbose components) (frontier)
wiredTigerEngineRuntimeConfig
WT_CACHE_FULL / Cache Pressure Troubleshooting (frontier, viability 4.30 / 5)
Corruption (validate, --repair, wt CLI)
Long-Running Transactions and Cache Pressure (frontier, viability 4.38 / 5)
MongoDB 8.0 WT Improvements (TCMalloc, ExpressPlan) (frontier, viability 2.60 / 5, below research gate)

Frontier under this node: Diagnostic Surface (serverStatus, FTDC, verbose components), Journal (Write-Ahead Log) (3.83), Long-Running Transactions and Cache Pressure (4.38), MVCC and Snapshot Isolation (3.67), MongoDB 8.0 WT Improvements (TCMalloc, ExpressPlan) (2.60), Prefix Compression (indexes) (2.95), Reconciliation and Page Splitting (3.02), Timestamp APIs (oldest/stable/pinned) (3.50), WT_CACHE_FULL / Cache Pressure Troubleshooting (4.30)

← the whole tree · 3D view· how to read this page