maaash.jp

what I create

memcachedのメモリ確保について

実戦で使ってるmemcachedがいっぱいになってきてるっぽいので勉強中
自分の理解を整理する。

memcached-toolでstatsを見る。
1MB_pagesはその1MB単位がいくつあるか

[homepage@www scripts]$ ./memcached-tool *.*.*.*:11211
# Item_Size Max_age 1MB_pages Count Full?
2 136 B 443801 s 22 169620 yes
3 176 B 550195 s 22 131053 yes
4 224 B 538853 s 10 46810 yes
5 280 B 580837 s 23 86112 yes
6 352 B 725477 s 24 71471 yes
7 440 B 816043 s 14 33362 yes
8 552 B 650550 s 10 18989 yes
9 696 B 734238 s 6 9036 yes
10 872 B 776224 s 7 8414 yes
11 1.1 kB 652671 s 14 13384 yes
12 1.3 kB 747239 s 10 7619 yes
13 1.7 kB 712451 s 8 4872 yes
14 2.1 kB 764616 s 13 6331 yes
15 2.6 kB 547465 s 22 8532 yes
16 3.3 kB 603087 s 11 3410 yes
17 4.1 kB 893787 s 44 10909 yes
18 5.2 kB 492512 s 21 4158 yes
19 6.4 kB 409549 s 20 3160 yes
20 8.1 kB 436414 s 22 2794 yes
21 10.1 kB 435327 s 22 2222 yes
22 12.6 kB 437689 s 19 1539 yes
23 15.8 kB 415113 s 21 1344 yes
24 19.7 kB 421321 s 90 4590 yes
25 24.6 kB 21065 s 77 3157 yes
26 30.8 kB 31859 s 101 3333 yes
27 38.5 kB 528086 s 150 3900 yes
28 48.1 kB 413215 s 132 2772 yes
29 60.2 kB 197636 s 43 731 yes
30 75.2 kB 182637 s 15 195 yes
31 94.0 kB 208702 s 10 99 yes
32 117.5 kB 399556 s 7 54 yes
33 146.9 kB 943288 s 5 28 yes
34 183.6 kB 754818 s 2 10 yes
35 229.5 kB 571672 s 4 16 yes
36 286.9 kB 335096 s 2 4 yes
37 358.6 kB 755830 s 3 6 yes
38 448.2 kB 62570 s 1 2 yes
39 1024.0 kB 279955 s 11 11 yes

全部Full!!
びびる!
FAQ読む

http://code.google.com/p/memcached/wiki/FAQ

memcachedのメモリ確保の方法はこちら
How does memcached’s memory allocation work? Why not use malloc/free!? Why the hell does it use slabs!?
http://code.sixapart.com/svn/memcached/trunk/server/doc/memory_management.txt

メモリは1MB単位で確保され(→slab)、Item_Sizeのclassを単位に分割される(→chunks)。
memcachedへのsetの要求に対して、順に分割されたchunks個数分までつっこめる。
この個数分の中で、least recently used (LRU) のキューができる。

この例だと
1MB * 22 / 136Byte = 169620

136Byteのclassが22page(=169620chunks)確保されていて、全部Full
136Byteのclassに割り当てられるようなサイズのデータをsetしようとしたら、
最も過去に使われたchunkが開放されて、そこにつっこむ。
そのカウントがevictions(有効期限の切れていないvalidなデータが消された回数)

Max_ageが最低なところを見ると、
24.6kBのclassを3157個格納していて、その最長有効期限が21065sec=5時間程度
ここもFullになってるってことは、もっと長い有効期限を設定しているのに
evictionsとなって消えていっているのかもしれない。
各slab毎のstatsは見れるのかな?

1.25倍区切りでclassの分割数が決まっていて、setしようとしているメモリサイズを格納するのに必要十分な最低のclassを使う。
140Byteのデータをsetしようとしたら176Byteのclassを使う、というように。
管理用のデータは別換算のようだから次に大きなclassを使うのかもしれない。
管理用のメモリサイズは読み取れなかった。

起動後、setの要求に対して、当てはまるclassのchunksに空きがなければ、
また1つslab(1MB分)を確保して、そのclassに当たるByte数(136とか)で分割してchunksを増やす。
-m で指定する最大メモリサイズまで使い切るまで、早いもの順で1MB確保して、chunksを増やしていく。

その結果、この例では
38.5 kB のclassが起動後、最大メモリサイズが確保されるまでに一番多く使われたのでしょう。
150MB割り当てられて、
1MB * 150 / 38.5kB = 3989個(実際には3900個になっている残りが管理領域なのか?)
使っている。

早いもの順だと、起動直後からのmemcachedの使い方に比較して、使い方のモードが変わったら、
memcachedの動作中に、頻繁に使用されるclassを分析してclassに対するpageを再割り当てする、
というのが
which is the next feature being worked on
って書いてあるのは実装されたんだろうか。

この文書は Date: Fri, 5 Sep 2003 20:31:03 +0300 のメールらしい。

Comments