Memcached item size limits and per-slab-class eviction tradeoffs

Direct answer

Raising the maximum item size with -I does not change the LRU eviction order inside the small-item slab classes. Small hot keys continue to be evicted only within their own slab class. The effect of a larger cap is confined to the larger slab classes that are added to accommodate the new size range.

Per-slab waste is best controlled by setting -I just above the largest item you actually need and keeping the slab growth factor modest for the small-item range. Splitting multi-megabyte values into smaller keys is operationally safer for mixed workloads, at the cost of application-level consistency for multi-key reads and writes.

Confirmed facts

• Memcached allocates memory in fixed-size slab classes. Each class maintains its own approximate LRU and evicts only within that class.
• A single item size is capped at startup with -I. The commonly cited default is near 1 MiB, but the exact default and the maximum allowed value are version and compile-time dependent.
• Slab class sizes grow by a factor set with -f. The long-standing default is ~1.25. Each class can waste up to roughly the growth factor minus one of its capacity.
• Changing -I adds larger slab classes; it does not modify the size or eviction behavior of existing small classes.

Likely explanation and tradeoffs

With a mixed workload of many small hot keys and occasional large values, per-class eviction means a hot small key can be evicted while a large-item slab class still has free space. Raising -I therefore does not rescue small keys, it only enables larger items to be stored.

Waste control for mixed sizes:

• Keep -I as low as possible while still fitting the largest expected item. An unnecessarily high cap creates extra large slab classes that sit mostly empty.
• With the default growth factor ~1.25, waste per class is on the order of up to ~20%. A smaller growth factor reduces internal fragmentation for small items but increases the total number of slab classes and metadata overhead.
• Practical tuning is workload specific. Many operators keep the default growth factor for small items and accept the waste, or use a slightly lower factor for the small-item range when small keys dominate memory use.

Splitting large values:

• Pros: avoids raising -I, keeps large items out of a dedicated large slab class, allows per-chunk LRU and reduces per-slab waste.
• Cons: requires application coordination for atomicity, versioning and consistency across the set of chunk keys. A partial write or eviction of one chunk leaves the reconstructed value inconsistent. Read amplification increases with the number of chunks.

Verification steps for this case

1. Confirm version and defaults: memcached -V
2. Inspect current slab layout and utilization: echo stats slabs | nc host port and review item size ranges, used vs free chunks per class.
3. If -I is changed, restart memcached with the new flag and re-run stats slabs to confirm new classes appear and small classes are unchanged.

Missing diagnostic detail that changes recommendation: the memcached version and the current stats slabs output showing utilization of the small-item classes versus the large-item classes. Without that, any specific -I and -f values remain assumptions.