Memcached Slab Allocator Tuning: Choosing Chunk Size and Growth Factor

Decision: Choosing Chunk Size and Growth Factor

When Memcached runs out of allocated memory, it triggers an eviction process. Because Memcached uses a slab allocator—grouping items of similar sizes into dedicated memory pools—you can experience premature evictions. This occurs when one slab class is full, forcing the system to evict the oldest item in that class even if several gigabytes of memory are sitting empty in other slab classes.

Constraints

The total memory limit (-m), the size distribution of your cached objects, and the need to balance internal fragmentation against the number of slab classes.

Comparison of Options

Data Profile	Strategy	Chunk Size (-c)	Growth Factor (-g)	Trade‑off
Small uniform keys (e.g., session IDs)	Tight granularity	64‑128 bytes	1.10‑1.20	More slab classes, higher metadata overhead
Variable size objects (HTML fragments)	Balanced	128‑256 bytes	1.25 (default)	Moderate internal fragmentation
Large bulky objects (serialized JSON)	Aggressive growth	256‑512 bytes	1.5‑2.0	Risk of large wasted space per item

Trade‑offs Explained

Chunk Size (-c)

The chunk size is the base unit for the smallest slab class. A small chunk size creates many slab classes for a wide size range, increasing the number of pointers Memcached must track. A large chunk size rounds up small objects, wasting memory inside each chunk.

Growth Factor (-g)

The growth factor determines how much each successive slab class grows. A lower factor (e.g., 1.1) yields finer granularity and less internal fragmentation but raises the total slab class count. A higher factor (e.g., 1.5) reduces class count but can leave large unused gaps for objects that fall just above a class boundary.

Validating Slab Health

Use the stats slabs command to see per‑class usage and evictions.

# Replace localhost and port if needed
echo 'stats slabs' | nc localhost 11211

Look for:

• high evictions in a specific slab while current_items in other slabs are low → slab imbalance
• bytes used approaching the total memory limit (-m) while total_items shows many allocated pages → potential need for more memory or better alignment

Example Diagnostic Decision

Suppose stats slabs returns:

STAT 1:chunk_size 96
STAT 1:chunks_per_page 1092
STAT 1:total_pages 1
STAT 1:total_chunks 1092
STAT 1:used_chunks 0
STAT 1:free_chunks 1092
STAT 1:free_chunks_end 0
STAT 1:mem_requested 0
STAT 1:get_hits 0
STAT 1:cmd_set 0
STAT 1:delete_hits 0
STAT 1:incr_hits 0
STAT 1:decr_hits 0
STAT 1:cas_hits 0
STAT 1:cas_badval 0
STAT 1:evictions 0
STAT 1:evicted_unfetched 0
STAT 2:chunk_size 120
STAT 2:chunks_per_page 873
STAT 2:total_pages 5
STAT 2:total_chunks 4365
STAT 2:used_chunks 4300
STAT 2:free_chunks 65
STAT 2:free_chunks_end 0
STAT 2:mem_requested 410000
STAT 2:get_hits 12000
STAT 2:cmd_set 13000
STAT 2:delete_hits 0
STAT 2:incr_hits 0
STAT 2:decr_hits 0
STAT 2:cas_hits 0
STAT 2:cas_badval 0
STAT 2:evictions 1200
STAT 2:evicted_unfetched 0
STAT 3:chunk_size 150
STAT 3:chunks_per_page 698
STAT 3:total_pages 0
STAT 3:total_chunks 0
STAT 3:used_chunks 0
STAT 3:free_chunks 0
STAT 3:free_chunks_end 0
STAT 3:mem_requested 0
STAT 3:get_hits 0
STAT 3:cmd_set 0
STAT 3:delete_hits 0
STAT 3:incr_hits 0
STAT 3:decr_hits 0
STAT 3:cas_hits 0
STAT 3:cas_badval 0
STAT 3:evictions 0
STAT 3:evicted_unfetched 0

Here slab 2 shows many evictions while slabs 1 and 3 are empty, indicating that objects around 120 bytes are filling that class and causing premature evictions despite free memory elsewhere. Raising the total memory limit or adjusting -c to better match the 120‑byte size would alleviate the issue.

Implementation and Rollback

To apply new settings, restart Memcached with the desired flags. Example: 1 GB limit, 128‑byte chunk, 1.1 growth factor.

# Run with sufficient privileges to bind the port
memcached -m 1024 -c 128 -g 1.1

Risk: Restarting clears all cached data, which can cause a cache stampede as requests hit the backend. Ensure the backend can absorb the load.

Rollback: Restart using the previous flags or the defaults (typically -c 64 -g 1.25).

Limitations

Slab allocation is static; chunk size and growth factor cannot be changed without a restart. Memcached cannot move memory from an empty slab to a full one, so internal fragmentation or slab imbalance persists until the cache is resized or the object size distribution changes.

Practical Verification

After restart, run the stats slabs command again and verify that evictions are low across all slabs and that bytes used align with your workload. If evictions remain high in a particular class, consider further tuning -c or -g or increasing -m.