How does the WiredTiger cache eviction process work

on
The WiredTiger cache contains data that is loaded into memory and ready for immediate use by WiredTiger. If WiredTiger is configured to use compression (Snappy by default), the content of the WiredTiger cache is the uncompressed version of the data. In contrast, the content of the filesystem cache is still compressed.
WiredTiger cache metrics are listed in the wiredTiger.cache document, and you can view specific fields using db.serverStatus().wiredTiger.cache["metric key"].

Default WiredTiger cache size

Starting in MongoDB 3.4, the WiredTiger internal cache, by default, uses the larger of either:
  • 50% of RAM minus 1 GB, or
  • 256 MB.
Relevant wiredTiger.cache metrics
  • maximum bytes configured

The eviction process

Clean vs dirty data

Clean (unmodified) refers to data in the cache that is identical to the version stored on disk.
Dirty (modified) refers to data in the cache that has been modified and is different from the data stored in disk.
  • If the cache contains clean data, eviction removes the content from cache without further processing.
  • If the cache contains dirty data, a consolidation step executes prior to eviction. This step synchronizes the data in the cache with the data on the disk.
Relevant wiredTiger.cache metrics
  • unmodified pages evicted
  • modified pages evicted

Eviction triggers

Eviction is triggered by any of these conditions:
  1. The cache is at or beyond a specific threshold.
    WiredTiger attempts to keep the cache below 80% of the configured cache size. If the cache grows beyond this threshold, eviction is triggered to keep the cache at 80%. Allowing the cache to grow beyond 80% may result in stalling, especially if the cache contains a lot of dirty data, as WiredTiger must evict cache content while serving client requests at the same time.
    For example, if the cache is set at 1 GB, eviction starts when the cache reaches 800 MB.
    Relevant wiredTiger.cache metrics
    • fill ratio = bytes currently in the cache / maximum bytes configured * 100
  2. The cache contains too much dirty data.
    When dirty data reaches a certain percentage of the total cache size (5% by default in MongoDB 3.4), the cache eviction process starts. This trigger prevents the WiredTiger checkpoints process from having to write a large amount of dirty data, which slows down the checkpoint process and may appear to users as stalls on systems with slow disks.
    Relevant wiredTiger.cache metrics
    • dirty fill ratio = tracked dirty bytes in the cache / maximum bytes configured * 100
  3. The page grows too large.
    Under certain workloads, such as bulk inserts of several megabyte documents or many updates to the same set of documents, the relevant in-memory page used by WiredTiger can grow beyond a set threshold (8 MB by default). To keep pages at a manageable size, the cache eviction process starts when a page grows beyond the threshold and prioritizes that page for eviction.
    Relevant wiredTiger.cache metrics
    • maximum page size at eviction
    • pages evicted because they exceeded the in-memory maximum

Eviction levels

  1. Under eviction thresholds: no action.
  2. Eviction target percentage (MongoDB 3.4 default is 80%): worker threads start the eviction process.
    Relevant wiredTiger.cache metrics
    • eviction worker thread evicting pages
  3. Eviction trigger percentage (MongoDB 3.4 default is 95%): application threads may contribute to the eviction process, limiting other database operations.
    Relevant wiredTiger.cache metrics
    • pages evicted by application threads
For more details, see WiredTiger eviction thresholds.

Eviction processes

Worker threads
  • spawned by WiredTiger to perform eviction work
  • configured by default as 4 threads in MongoDB 3.4
Application threads
  • spawned by MongoDB to handle client requests
  • the number depends on how many connections clients open to MongoDB
When entering the storage engine, application threads perform eviction if required prior to doing any other operation. For example:
  1. Client connects to MongoDB, spawning an application thread in MongoDB.
  2. Client sends a find command.
  3. Application thread enters WiredTiger.
  4. Application thread checks if required to perform eviction. If yes, it performs eviction first before doing anything else.
  5. Application thread completes the find command.
The use of application threads to help the eviction process throttles other operations going into WiredTiger. This ensures that evictions, especially dirty pages evictions, take priority when the server is busy or is interfacing with a slow disk.

Comments

Post a Comment