blob: bae069a2cb7dfe32d7682dca96ef93c044d275db (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
|
/*! @page cache_configuration Cache configuration
@section cache_basic Cache configuration
The WiredTiger cache implements an approximation of a least recently used
algorithm. 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
@ref wiredtiger_open or changed after open using the
WT_CONNECTION::reconfigure method.
@section shared_cache 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 @ref 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 @ref wiredtiger_open or changed after open using the
WT_CONNECTION::reconfigure method.
@section cache_eviction 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 @ref wiredtiger_open or changed after open using the
WT_CONNECTION::reconfigure method.
*/
|
