SERVER_ERROR object too large for cache in memcached: raise -I or chunk large values?

Short answer

Neither option is universally correct — the deciding factor is the shape of your value-size distribution. If oversized values are rare outliers (a few percent of writes), keep the default 1 MB limit and fix them in the application: compress first, chunk only if compression isn't enough. If large values are the dominant shape of the workload (e.g., serialized object graphs or rendered pages that are naturally 1–5 MB) and readers need atomic single-key reads, raising -I is the cleaner choice despite the restart.

Workload conditions that favor raising -I

• Most values sit just above 1 MB, so chunking would split the majority of your traffic, not an edge case.
• Values are written once and read atomically — you cannot tolerate a reader observing a mix of old and new chunks mid-write.
• You can schedule a restart (which flushes the entire cache) and absorb or pre-warm the resulting cold-start load on your backing store.
• You have headroom to re-tune memory, because larger slab classes change allocation economics (below).

Conditions that favor chunking or compression

• Oversized values are a small fraction of writes — a restart and cache flush is a high price for outliers.
• Cache availability during deploys matters; chunking requires no daemon change.
• The large value decomposes into independently cacheable parts, which can actually improve hit rates.
• Payloads are JSON/HTML/text: try client-side compression first. It often brings values under 1 MB at modest CPU cost. Caveats: all readers must agree on the codec, and stored bytes become opaque to get/telnet debugging.

Remember chunking's real cost: there is no atomicity across keys, and one missing or evicted chunk fails the whole value.

Detecting slab memory waste after raising -I

memcached allocates 1 MB pages and splits them into fixed-size chunks per slab class; each stored item rounds up to the next class's chunk size. A larger -I creates larger classes, and a handful of huge items can pin entire pages in a sparsely populated class. The warning signs, visible via the text protocol:

printf 'stats slabs\nstats items\n' | nc localhost 11211

• A large gap between used_chunks and total_chunks in the largest slab classes — memory allocated but mostly empty.
• Rising evictions or a falling hit rate even though bytes is well below limit_maxbytes — pages are stranded in the wrong classes.

If you see this, either lower -I back down, or adjust the slab growth factor (-f) so class sizes track your actual distribution more tightly.

Before you decide

1. Log serialized value sizes at the client to learn whether large values are outliers or the norm.
2. Test compression ratios on representative payloads.
3. Check the maximum supported -I for your build — it is version-dependent; run memcached -h and confirm.
4. Rehearse the restart in staging: the flush is total, so plan cache warming or a traffic ramp.

Assumes a mainstream memcached 1.4/1.5/1.6-era build; exact limits and stats field names should be verified against your installed version.