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

Memcached allocates memory through fixed-size slab classes, and each class maintains its own approximate LRU for eviction. The size of a single item is capped—commonly near 1 MiB by default and adjustable through the documented -I startup option—so larger values must either be split across keys or accommodated by raising the limit.

The unresolved decision is how to size items for a mixed workload that pairs many small, frequently accessed keys with occasional multi-megabyte values. Raising the cap introduces larger slab classes where each allocation can waste more space, and per-class eviction means a hot small key can still be evicted while another slab class retains unused memory. Compile-time and startup settings vary across deployments, so published defaults may not match a given instance.

Specific questions:

1. Does raising the maximum item size materially change eviction behavior for small hot keys, or is the effect confined to the slab classes that hold larger items?
2. What combination of item size cap and slab growth factor keeps per-slab waste acceptable when small and large values coexist?
3. Is splitting large values into multiple smaller keys generally the safer operational choice, and what consistency tradeoffs does that introduce?