Eviction

	Data Structures	Source Location
	WT_EVICT_ENTRY WT_EVICT_QUEUE	src/include/cache.h src/evict/

Caution: the Architecture Guide is not updated in lockstep with the code base and is not necessarily correct or complete for any specific release.

Eviction

The goal of eviction is to manage the Cache and keep the cache in the margin set by the user. There is an upper limit for the total content and dirty content, whenever the cache goes above the target then eviction gets triggered to bring it down under the limits.

Eviction is managed using WT_EVICT_QUEUE structures, each of which contains a list of WT_EVICT_ENTRY structures.

Eviction is composed of one eviction server, zero or more eviction worker threads and three shared eviction_queues (two ordinary queues and one urgent queue). The eviction server's goal is to find the pages that can be evicted. It has to walk the pages in a tree, one tree after the other, and find evictable candidates. It makes fair judgments between the trees, remembers where it was in a tree, and proceeds to the next tree from there. It extracts all the pages that can be evicted, sorts them based on when they were accessed last, and takes one-third oldest of the evictable candidates. This simulates an approximate Least Recently Used (LRU) algorithm, as the references to these pages are then pushed into the eviction_queues. The whole goal is to remove the content which is older to be evicted and put it in the queue. A user can configure a minimum and a maximum number of eviction worker threads to be created through the connection configuration string. The goal of eviction worker threads is to pop the pages from the queues and evict them. Eviction worker threads wait for queues to be populated, working with the eviction server through a CV signaling mechanism. They then get to evicting the pages independently to the server, till the eviction queues are not empty. There is a mechanism where the number of worker threads can be scaled dynamically between the provided range. With this mechanism, the system automatically adjusts the available worker threads to an optimum number that gives a good eviction performance, while minimizing the overhead of having a lot of eviction threads.

It is possible to have just the eviction server and no worker threads. In such a case, the eviction server walks the tree to find pages to evict and evict these pages from the cache. Pages that are being marked for forced eviction go onto the urgent queue, and these pages take precedence over the pages from the ordinary eviction queues.

If there are other threads reading the content, the page cannot be evicted and the eviction server/worker threads check for that. Eviction has to lock and get exclusive access to the page so that after having checked if the page is evictable and starting to evict, a parallel reader doesn't start to access it.

Clean vs dirty data

• Clean refers to data in the cache that is identical to the version stored on disk.
• Dirty refers to data in the cache that has been modified and needs to be reconciled with the data stored on the disk.

Clean vs dirty eviction

• In the case of clean eviction, there is no dirty content on the page and it is directly removed from the memory. After that, the page remains solely on the disk unchanged.
• In the case of dirty eviction, the dirty page goes through reconciliation. The obsolete content on the page is thrown out, the latest value goes to the data store and older values go to the history store.

Sometimes the workload generates enough new data that eviction is unable to reduce the cache content and more new content is put into cache that can be removed by eviction. In such a case application threads are also forced to do the work of eviction workers threads, before they can read or write more data.

Eviction triggers and targets

WiredTiger provides several configuration options for tuning how pages are evicted from the cache.

WiredTiger eviction tuning options can be configured when first opening a database via wiredtiger_open, or changed after open with WT_CONNECTION::reconfigure.

The eviction_target configuration value is the level at which WiredTiger attempts to keep the overall cache usage. Eviction worker threads are active when the cache contains at least this much content, expressed as a percentage of the total cache size.

The eviction_trigger configuration value is the level at which application threads start to perform the eviction.

The eviction_dirty_target and eviction_dirty_trigger operate in a similar way to the overall targets but only apply to dirty data in cache. In particular, application threads will be throttled if the percentage of dirty data reaches the eviction_dirty_trigger. Any page that has been modified since it was read from disk is considered dirty.

The eviction_updates_target perform eviction in worker threads when the cache contains at least this many bytes of updates

The eviction_updates_trigger trigger application threads to perform eviction when the cache contains at least this many bytes of updates.

It is worth noting that for all eviction target and trigger sizes, the target size must be lower than its trigger size counterpart.