Memcached: Slab Allocation Internals
If you're using malloc and free for every small object in a high-traffic cache, you're going to fragment your heap into oblivion. Memcached avoids this by implementing its own memory manager: the Slab Allocator.
The Slab Concept
Memcached pre-allocates large chunks of memory (usually 1MB) called "Slab Pages." These pages are then sliced into smaller "chunks" of fixed sizes.
# View slab statistics
$ memcached-tool 127.0.0.1:11211 display
# Item_Size Max_age Pages Count Full?
1 96B 3600s 1 100 no
2 120B 3600s 1 50 no
Choosing a Slab
When you store an item, Memcached calculates its size and finds the slab class that fits it best. If your item is 100 bytes, it goes into the 120-byte slab (if 96 is too small).
/* Internal conceptual logic for slab selection */
slabclass_id_t slabs_clsid(const size_t size) {
int res = POWER_SMALLEST;
if (size == 0) return 0;
while (size > slabclass[res].size) {
if (res++ == slabclass_max_id) return 0;
}
return res;
}
The Downside: Internal Fragmentation
The trade-off for zero external fragmentation is internal fragmentation. If you have many items that are just 1 byte larger than a slab size, you waste space. You can tune this with the -f (growth factor) parameter:
# memcached -m 1024 -f 1.05 -u root
By using a smaller growth factor, you get more slab classes that are closer together in size, reducing waste at the cost of slightly more metadata overhead. If you're not tuning your slabs, you're not really using Memcached.
Aunimeda provides DevOps engineering and infrastructure services - CI/CD pipelines, containerization, cloud deployments, and monitoring setups.
Contact us to discuss your infrastructure needs. See also: DevOps Services, Custom Software Development