2
From: Trond Norbye <trond.norbye@sun.com>
4
When started with -L memcached will try to enable large memory
5
pages, and preallocate all memory up front. By using large memory
6
pages memcached could reduce the number of TLB misses (depending
7
on the access pattern), and hence improve performance.
9
See http://en.wikipedia.org/wiki/Translation_lookaside_buffer for
12
Date: Fri, 5 Sep 2003 20:31:03 +0300
13
From: Anatoly Vorobey <mellon@pobox.com>
14
To: memcached@lists.danga.com
15
Subject: Re: Memory Management...
17
On Fri, Sep 05, 2003 at 12:07:48PM -0400, Kyle R. Burton wrote:
18
> prefixing keys with a container identifier). We have just begun to
19
> look at the implementation of the memory management sub-system with
20
> regards to it's allocation, de-allocation and compaction approaches.
21
> Is there any documentation or discussion of how this subsystem
22
> operates? (slabs.c?)
24
There's no documentation yet, and it's worth mentioning that this
25
subsystem is the most active area of memcached under development at the
26
moment (however, all the changes to it won't modify the way memcached
27
presents itself towards clients, they're primarily directed at making
28
memcached use memory more efficiently).
30
Here's a quick recap of what it does now and what is being worked
33
The primary goal of the slabs subsystem in memcached was to eliminate
34
memory fragmentation issues totally by using fixed-size memory chunks
35
coming from a few predetermined size classes (early versions of
36
memcached relied on malloc()'s handling of fragmentation which proved
37
woefully inadequate for our purposes). For instance, suppose
38
we decide at the outset that the list of possible sizes is: 64 bytes,
39
128 bytes, 256 bytes, etc. - doubling all the way up to 1Mb. For each
40
size class in this list (each possible size) we maintain a list of free
41
chunks of this size. Whenever a request comes for a particular size,
42
it is rounded up to the closest size class and a free chunk is taken
43
from that size class. In the above example, if you request from the
44
slabs subsystem 100 bytes of memory, you'll actually get a chunk 128
45
bytes worth, from the 128-bytes size class. If there are no free chunks
46
of the needed size at the moment, there are two ways to get one: 1) free
47
an existing chunk in the same size class, using LRU queues to free the
48
least needed objects; 2) get more memory from the system, which we
49
currently always do in _slabs_ of 1Mb each; we malloc() a slab, divide
50
it to chunks of the needed size, and use them.
52
The tradeoff is between memory fragmentation and memory utilisation. In
53
the scheme we're now using, we have zero fragmentation, but a relatively
54
high percentage of memory is wasted. The most efficient way to reduce
55
the waste is to use a list of size classes that closely matches (if
56
that's at all possible) common sizes of objects that the clients
57
of this particular installation of memcached are likely to store.
58
For example, if your installation is going to store hundreds of
59
thousands of objects of the size exactly 120 bytes, you'd be much better
60
off changing, in the "naive" list of sizes outlined above, the class
61
of 128 bytes to something a bit higher (because the overhead of
62
storing an item, while not large, will push those 120-bytes objects over
63
128 bytes of storage internally, and will require using 256 bytes for
64
each of them in the naive scheme, forcing you to waste almost 50% of
65
memory). Such tinkering with the list of size classes is not currently
66
possible with memcached, but enabling it is one of the immediate goals.
68
Ideally, the slabs subsystem would analyze at runtime the common sizes
69
of objects that are being requested, and would be able to modify the
70
list of sizes dynamically to improve memory utilisation. This is not
71
planned for the immediate future, however. What is planned is the
72
ability to reassign slabs to different classes. Here's what this means.
73
Currently, the total amount of memory allocated for each size class is
74
determined by how clients interact with memcached during the initial
75
phase of its execution, when it keeps malloc()'ing more slabs and
76
dividing them into chunks, until it hits the specified memory limit
77
(say, 2Gb, or whatever else was specified). Once it hits the limit, to
78
allocate a new chunk it'll always delete an existing chunk of the same
79
size (using LRU queues), and will never malloc() or free() any memory
80
from/to the system. So if, for example, during those initial few hours
81
of memcached's execution your clients mainly wanted to store very small
82
items, the bulk of memory allocated will be divided to small-sized
83
chunks, and the large size classes will get fewer memory, therefore the
84
life-cycle of large objects you'll store in memcached will henceforth
85
always be much shorter, with this instance of memcached (their LRU
86
queues will be shorter and they'll be pushed out much more often). In
87
general, if your system starts producing a different pattern of common
88
object sizes, the memcached servers will become less efficient, unless
89
you restart them. Slabs reassignment, which is the next feature being
90
worked on, will ensure the server's ability to reclaim a slab (1Mb of
91
memory) from one size class and put it into another class size, where
added
removed
doc/memory_management.txt
