Slab Reassignment vs. Manual Growth Factor Tuning for Eviction Control

Short answer

For workloads with highly volatile object sizes, slab_reassign (together with slab_automove) is generally the more effective strategy. Growth factor tuning only pays off when you can predict the item-size distribution — and volatility is precisely the condition where that prediction fails. A static layout tuned for yesterday's traffic becomes the wrong layout when the distribution shifts, and Memcached cannot retune the growth factor on a live daemon; -f applies only at startup to an empty cache.

Why reassignment fits volatile workloads

Memcached's slab allocator gives each slab class its own LRU. When one class fills, it evicts its own items even while other classes sit on free pages — the classic "premature eviction" pattern where overall memory usage is low but one class churns. Slab reassignment attacks exactly this: the daemon moves whole 1MB pages from classes with reclaimable capacity to classes under eviction pressure. When object sizes swing unpredictably, this dynamic redistribution is the only mechanism that can follow the workload, because no fixed class geometry fits a moving target.

When reassignment loses to a tuned growth factor

Reassignment is not free, and there are two specific pressure conditions where it underperforms a statically tuned layout:

• Sustained, uniform pressure across all slab classes. Reassignment works by stealing pages from slabs that have free or evictable capacity. If every class is genuinely full, there is nothing to move. The automove background scanning and migration logic then adds overhead with zero benefit, while a growth factor matched to the real distribution would have minimized wasted bytes per item from the start.
• Sudden bursts concentrated in one size class. Page migration is not instantaneous. A sharp spike can trigger a burst of evictions before pages are relocated — the "eviction noise" you are trying to suppress. A growth factor pre-tuned to the burst profile has the capacity already in place and suffers no lag.

Reassignment also cannot fix fragmentation within a page, and it moves pages in 1MB units, so it is a coarse instrument.

Confirm the problem before choosing

First verify you actually have slab imbalance rather than simple memory exhaustion. The signature is high evictions in one or two classes while others show free chunks:

stats slabs
stats items
stats settings

Compare evicted per class against used_chunks and free pages. If evictions track total memory pressure evenly, neither tuning strategy helps — you need more RAM or smaller items. Also confirm via stats settings which slab_reassign, slab_automove, and factor values the running daemon actually has; these behaviors are version-sensitive, and older automove algorithms had known misbehavior, so check your Memcached version's release notes before enabling it in production.

A practical decision path

1. If item sizes are volatile and unpredictable: enable slab_reassign/slab_automove on a staging instance, replay representative traffic, and compare evictions and hit ratio against your baseline.
2. If you discover the distribution is actually stable (common after measuring): tune -f to match it, restart with a warm-up plan, and you avoid migration overhead entirely.
3. If bursts are the problem, simulate a single-class burst in staging and measure how long evictions continue after enabling reassignment — that lag quantifies whether automove reacts fast enough for your traffic.

One caveat worth noting: modern Memcached (1.5+) includes the segmented LRU and lru_maintainer, which reduce eviction noise independently of slab layout. If you are on an older build, upgrading may shrink the problem before you touch either knob. The one diagnostic detail that would change this recommendation is your per-class eviction breakdown from stats slabs — if pressure is uniform, skip reassignment entirely.