株式会社ミクシィ 研究開発グループの前坂です。前回の記事でmemcachedは分散に長けた高速なキャッシュサーバであることが紹介されました。今回はmemcachedの内部構造がどう実装されているのか，そしてメモリがどう管理されているのかをご紹介します。また，memcachedの内部構造の事情による弱点も紹介します。

メモリを整理して再利用するSlab Allocationメカニズム

昨今のmemcachedはデフォルトでSlab Allocatorというメカニズムを使ってメモリの確保・管理を行っています。このメカニズムが登場する以前のメモリ確保の戦略は，単純にすべてのレコードに対してmallocとfreeを行うといったものでした。しがしながら，このアプローチではメモリにフラグメンテーション（断片化）を発生させてしまい，OSのメモリマネージャに負荷をかけ，最悪の場合だとmemcachedのプロセスよりも重くなってしまうという問題が発覚しました。この問題を克服するために生まれたのがSlab Allocatorです。

Slab Allocatorの仕組みを見てみましょう。以下がmemcachedのドキュメントから引用したslab allocatorの目標です：

the primary goal of the slabs subsystem in memcached was to eliminate memory fragmentation issues totally by using fixed-size memory chunks coming from a few predetermined size classes.

つまりSlab Allocatorの基本は確保したメモリをあらかじめ決められたクラスサイズに応じた固定長の固まりに分けて，フラグメンテーション問題を完全に克服するということです。

Slab Allocationの仕組みは簡素で，確保したメモリをさまざまなサイズの固まり（chunk）に分けて，同じサイズの固まりをクラス（chunkの集合，またはchunkのサイズを定めるクラス）に整理します（図1）。

また，slab allocatorには「確保したメモリは再利用する」という目標もあります。したがって，memcachedは一度確保したメモリは解放せず，常にchunkを再利用します。

Slab Allocatorの主な用語

Page

デフォルトで1MB確保され，Slabに割り当てられるメモリ領域。Slabに割り当てられた後に，slabのサイズに応じたchunkに切り分けられる。

Chunk

レコードをキャッシュするためのメモリ領域。

Slab Class

特定のサイズのchunkをまとめるクラス。

Slabにレコードをキャッシュする仕組み

クライアントから送信されたデータを，memcachedはどのようにslabを選び，chunkにキャッシュするかを説明します。

memcachedは受けとったデータのサイズを参照し，データサイズにもっとも適したslabを選びます（図2）。memcachedはslab内の使用可能なchunkのフリーリストを保持しているので，このリストを基にchunkを選び，そこにキャッシュします。

ここまで紹介したSlab Allocatorですが，利点ばかりではなく弱点も存在します。次はその弱点を説明します。