Understanding Memcached Slab Allocation and Why Evictions Can Happen With Free Memory

You're monitoring your Memcached instance and notice the eviction rate climbing, yet the total memory usage reported by stats is far below the limit you set with -m. At first glance this looks like a leak or a mis‑configuration. The real cause is Memcached’s slab‑based allocator, which can leave whole pages unused while a specific size class runs out of room and starts evicting.

How the Slab Allocator Works

When Memcached starts it reserves the amount of memory you gave it (default 64 MB) and splits that reserve into 1 MB pages. Each page is then cut into equal‑sized chunks that belong to a slab class. All chunks in a class have the same size, for example 96 bytes, 128 bytes, 162 bytes, and so on, growing by a factor (≈1.25 by default). When you store an item, Memcached picks the smallest class whose chunk size fits the item and places the item in one of those chunks. Any leftover space inside the chunk becomes internal fragmentation and cannot be used for other items.

The advantage is O(1) allocation and freedom from external fragmentation. The trade‑off is that memory is partitioned by size, so a workload that heavily uses one size can fill its class while other classes stay empty.

Worked Example: Size Shift Causes Class‑Specific Evictions

1. Start a small test instance: memcached -m 16 -p 11211
2. Connect with telnet or netcat: nc localhost 11211
3. Store a thousand 200‑byte items (use set key 0 60 200 followed by the data).
4. Store a thousand 900‑byte items in the same way.
5. Run stats slabs and examine the output.

You will see that the slab class whose chunk size is just over 900 bytes reports a rising evictions count, while the class for ~200‑byte chunks shows few or no evictions. The total bytes used may still be far below the 16 MB limit, demonstrating that free memory exists in other classes but cannot be reclaimed for the 900‑byte workload.

Limitations and Mitigations

• Internal fragmentation: Storing a 210‑byte item in a 256‑byte chunk wastes 46 bytes. The waste grows with the size‑growth factor.
• Slab calcification (classic behavior): Pages, once assigned to a class, stay there unless you enable reassignment.
• Modern options (1.5+): -o slab_reassign lets Memcached move pages from under‑used classes to over‑loaded ones; the LRU crawler reaps expired items more promptly.
• Practical guidance: Keep cached values as uniform in size as possible, monitor stats items for evictions and reclaims per class, and set the memory limit (-m) deliberately rather than relying on the default.

Actionable Checklist

• Launch Memcached with a verbose flag to see allocation messages: memcached -m 64 -vv.
• After a representative load, run stats slabs and note any class where evictions is increasing while curr_items is high.
• If you observe class‑specific evictions, consider enabling slab reassignment (-o slab_reassign) or splitting your cache into multiple instances for different data shapes.
• Set -m based on your peak expected usage, and verify with stats that total bytes stays comfortably below that limit.