blob: 47ef2578c01987788c310cda80471b997b869327 (
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
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
|
/*! @page cache_configuration Cache configuration
@section cache_basic 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
@ref wiredtiger_open or changed after open using the
WT_CONNECTION::reconfigure method.
@section tuning_cache_size Cache size
The cache size for the database is configurable by setting the \c 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:
@snippet ex_config.c configure cache size
@section tuning_cache_resident 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:
@snippet ex_all.c Create a cache-resident object
@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.
*/
|
