Cache configuration

The WiredTiger cache implements an approximation of a least recently used algorithm. The size of the cache is the single most important tuning knob for a WiredTiger application. Ideally the cache should be configured to be large enough to hold an application's working set.

The WiredTiger cache size can be configured when first opening a database via wiredtiger_open or changed after open using the WT_CONNECTION::reconfigure method.

Cache size

The cache size for the database is configurable by setting the cache_size configuration string when calling the wiredtiger_open function.

The effectiveness of the cache can be measured by reviewing the page eviction statistics for the database.

An example of setting a cache size to 500MB:

        if ((ret = wiredtiger_open(home, NULL,
            "create,cache_size=500M", &conn)) != 0)
                fprintf(stderr, "Error connecting to %s: %s\n",
                    home, wiredtiger_strerror(ret));

Cache resident objects

Cache resident objects (objects never considered for the purposes of cache eviction), can be configured with the WT_SESSION::create "cache_resident" configuration string.

Configuring a cache resident object has two effects: first, once the object's pages have been instantiated in memory, no further I/O cost is ever paid for object access, minimizing potential latency. Second, in-memory objects can be accessed faster than objects tracked for potential eviction, and applications able to guarantee sufficient memory that an object need never be evicted can significantly increase their performance.

An example of configuring a cache-resident object:

ret = session->create(session,

"table:mytable", "key_format=r,value_format=S,cache_resident=true");

Shared cache configuration

WiredTiger supports sharing a single cache among multiple databases within a process.

An application configures a shared cache by specifying a shared_cache name to the wiredtiger_open function. Applications can optionally set a minimum amount of cache any connection in the pool will be assigned and the granularity at which the cache pool is redistributed among connections - called the chunk size.

The shared cache implementation assigns a certain amount of cache to each participating database. Each database manages its allocated cache as it would when not using a shared cache - thus databases using a shared cache can have different eviction policies. There is a thread that monitors the cache usage of each database and redistributes the cache among participants according to where it is most likely to improve performance. The cache is redistributed in chunks which are of a configurable size. Once a database has had a chunk of cache added or removed it will be given time to start effectively using that cache before it is considered for further adjustment. If a small chunk size is configured it will take longer for the shared cache to adjust to changes in participants. Reallocation of resources happens periodically and whenever a database joins the shared cache.

The reallocation of resources is determined by comparing the amount of eviction activity in a particular database to that of the other participating databases.

When a database is opened it will be allocated the amount of cache configured as the shared cache minimum, regardless of whether the cache pool is currently fully utilized. Other databases will have their assigned cache size reduced so the total cache size used will return within the bounds - there may be a period when the actual usage exceeds the configured maximum. This is especially likely if many databases join the shared cache in a short period. When a database is closed any resources it is using are distributed among the other databases.

WiredTiger shared cache tuning options can be configured when first opening a database via wiredtiger_open or changed after open using the WT_CONNECTION::reconfigure method.

Eviction configuration

WiredTiger provides several configuration options for tuning how aggressively pages are evicted from the cache. Different values will result in better performance depending on an application's particular workload.

In WiredTiger cache eviction is handled by a separate thread. It is possible to configure the percentage of cache that needs to be used before the eviction thread will attempt to find pages to free. It is also possible to configure a target percentage which is the percentage of the cache that needs to be free before the eviction server sleeps.

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