Understanding Memcached Slab Allocation and LRU Behavior

Use the following command to start memcached: memcached -vv -m 1 -I 1k -f 3 -M Options: -vv for verbose output, -m 1 sets maximum 1 MB cache, -I 1k defines 1 KB page size, -f 3 sets chunk size growth factor of 3, -M returns an error when memory is exhausted.

Output:

slab class   1: chunk size        96 perslab      10
    slab class   2: chunk size       288 perslab       3
    slab class   3: chunk size      1024 perslab       1
    <26 server listening (auto-negotiate)
    <27 server listening (auto-negotiate)
    <28 send buffer was 9216, now 5592405
    ... (additional server messages) ...

Visual representation:

We have a 1 MB cache (default memory allocation) divided into 1 KB pages. Pages are allocated on a first‑come‑first‑served basis to three slab classes, and once assigned they remain fixed. The slab classes are determined by page size and the chunk‑size growth factor.

In our configuration, slab 1 uses a 96‑byte chunk (the smallest size) with 10 chunks per page (11 × 96 > 1024). Slab 2 uses a 288‑byte chunk (96 × 3 growth factor) with 3 chunks per page. Slab 3’s chunk size is close to the page size, so each page holds only one chunk.

Each chunk stores items whose size matches the chunk size range. Small items (e.g., 40 B or 60 B) go to slab 1, medium items (96 B–288 B) to slab 2, and larger items (288 B–1024 B) to slab 3. Placing a 60‑byte item in a 96‑byte chunk wastes 36 bytes, which cannot be used for other items.

This is the overall overview of Memcached storage: pages, chunks, and slabs. If all pages are used for only small and large items, medium‑sized items cannot be stored.

Eventually you might have 800 slab 1 pages and 200 slab 3 pages, which works fine until a medium‑sized item is added.

At this point Memcached throws a memory‑exhaustion error because slab 2 cannot obtain a free page; pages allocated to slab 1 and slab 3 are not re‑assigned to slab 2. Memcached maintains an internal cache that defines these slab classes.

Regarding LRU, each slab class has its own independent cache with a local LRU; there is no global LRU. Consequently, the least‑recently‑used item in one slab is not evicted when another slab receives new items, potentially leaving long‑unused items in memory.

Items and chunks are not actively reclaimed or expired. Memcached does not run a background thread to identify expired items; when a slab needs a chunk and no free page is available, it evicts items from the tail of the queue. In some scenarios, an expired item may be removed, while in others a non‑expired item is evicted because the expired one is not at the queue tail.

Author: Ma Ya, Core Engineer, Hotel Business Unit, Qunar.

Article originally from the company wiki “Hotel Development Team’s 1001 Nights”. Qunar colleagues can log in to the wiki for more articles.