> The memory allocation is a bit more subtle... but it's hard to explain and > doesn't really affect anyone. > > Urr... I'll give it a shot. > > ./memcached -m 128 > ^ means memcached can use up to 128 megabytes of memory for item storage. > > Now lets say you store items that will fit in a slab class of "128", which > means 128 bytes for the key + flags + CAS + value. > > The maximum item size is (by default) 1 megabyte. This ends up being the > ceiling for how big a slab "page" can be. > > 8192 128 byte items will fit inside the slab "page" limit of 1mb. > > So now a slab page of 1mb is allocated, and split up into 8192 "chunks". > Each chunk can store a single item. > > Slabs grow at a default factor of 1.20 or whatever -f is. So the next slab > class after 128 bytes will be 154 bytes (rounding up). (note I don't > actually recall offhand if it rounds up or down :P) > > 154 bytes is not evenly divisible into 1048576. You end up with > 6808.93 chunks. So instead memcached allocates a page of 1048432 bytes, > providing 6,808 chunks. > > This is slightly smaller than 1mb! So as your chunks grow, they > don't allocate exactly a megabyte from the main pool of "128 megabytes", > then split that into chunks. Memcached attempts to leave the little scraps > of memory in the main pool in hopes that they'll add up to an extra page > down the line, rather than be thrown out as overhead when if a slab class > were to allocate a 1mb page. > > So in memcached, a slab "page" is "however many chunks of this size will > fit into 1mb", a chunk is "how many chunks will fit into that page". The > slab growth factor determines how many slab classes exist. > > I'm gonna turn this into a wiki entry in a few days... been slowly > whittling away at revising the whole thing.
To be most accurate, it is "how many chunks will fit into the max item size, which by default is 1mb". The page size being == to the max item size is just due to how the slabbing algorithm works. It creates slab classes between a minimum and a maximum. So the maximum ends up being the item size limit. I can see this changing in the future, where we have a "max item size" of whatever, and a "page size" of 1mb, then larger items are made up of concatenated smaller pages or individual malloc's.
