Choosing Memcached Slab Growth Factor for Efficient Memory Use

Decision and constraints

When deploying Memcached you must decide how the slab allocator will grow its size classes. The allocator uses a growth factor (‑I) to determine the size of each subsequent slab class. A poorly chosen factor can cause over‑allocation (wasted memory) or frequent evictions even when total memory appears free. The decision is constrained by:

• Expected object size distribution in your workload.
• Total memory you can allocate to Memcached (‑m).
• Operational tolerance for a restart, because changing ‑I requires a full cache flush.

Supported options

Growth factor (‑I)	Typical use case	Memory efficiency	Risk of over‑allocation
1.10	Workloads with many small, uniform objects (e.g., 100‑byte keys/values)	High – slab classes closely match object sizes	Low – small steps reduce wasted space
1.25 (default)	General purpose workloads with a moderate size spread	Medium – reasonable balance	Medium – occasional boundary overruns
1.50	Workloads with large, variable objects (e.g., multi‑KB values)	Lower – larger steps increase internal fragmentation	High – objects just above a class jump to a much larger slab

Trade‑offs

A smaller growth factor creates more slab classes, giving finer granularity and less wasted memory per item. However, it increases the number of slabs that must be managed, which can slightly raise overhead for the allocator and may lead to more frequent page allocations if the workload has a wide size spread. A larger factor reduces the number of classes and allocator overhead but raises the chance that an item will be placed in a slab significantly larger than needed, wasting memory and potentially triggering evictions when the larger slab fills.

Concrete implementation

Suppose your application stores mostly 250‑byte JSON blobs and you have 2 GB of memory available for Memcached. You decide to start with a tighter growth factor to match the 250‑byte size.

1. Stop the existing Memcached instance (this will clear the cache).
2. Start Memcached with the new factor:

# Run as a user with permission to bind port 11211 (e.g., the memcached user)
memcached -m 2048 -I 1.10 -p 11211 -u memcached

Replace 2048 with your desired memory limit in MB, 1.10 with the chosen growth factor, and 11211 with the port you intend to use.

Validation and verification

After the instance is running, inspect slab statistics to confirm that the new class layout reduces wasted bytes.

1. Connect to the Memcached port via telnet or netcat:

telnet localhost 11211

Then issue the stats slabs command:

stats slabs

Look for the slab class whose size is closest to your object size (e.g., the class around 256 bytes). Check the fields:

• chunk_size – size of each chunk in that class.
• used_chunks vs chunks_per_page – indicates how much of the slab is actually occupied.
• wasted_bytes – memory lost to internal fragmentation in that class.

A low wasted_bytes relative to chunk_size * used_chunks shows good alignment. If you see high wasted bytes, consider adjusting the factor upward or downward and repeat the test after a restart.

Additionally, monitor overall evictions with stats:

stats

Watch the evictions counter; a persistently high value may indicate that slab misalignment is causing premature ejects even though total memory is not exhausted.

Limitations

• Changing ‑I requires a full restart, which flushes all cached data.
• The optimal factor is workload‑dependent; a shift in object size distribution may render a previously tuned factor sub‑optimal.
• Extremely small factors (e.g., <1.10) can create many slab classes, increasing allocator overhead and potentially causing more frequent page allocations.

Rollback

If the new factor proves unsuitable, restart Memcached with the previous ‑I value (or the default 1.25) using the same -m and -p settings. This will again clear the cache, so plan the rollback during a maintenance window or when warm‑up traffic can tolerate a cold start.