> Some details here: > http://dev.mysql.com/doc/refman/5.0/en/ha-memcached-using-memory.html > > thanx for this link. Some details in the text are confusing to me. It says: > > When you start to store data into the cache, memcached does not > allocate the memory for the data on an item by item basis. Instead, a slab > allocation is used to optimize memory usage and > prevent memory fragmentation when information expires from the cache. > > > With slab allocation, memory is reserved in blocks of 1MB. The slab is > divided up into a number of blocks of equal size. > > Ok, blocks of equal size, all blocks have 1 MB (as said in the sentence > before). > > When you try to store a value into the cache, memcached checks the size > of the value that you are adding to the cache and determines which slab > contains the right size allocation for the item. > If a slab with the item size already exists, the item is written to the > block within the slab. > > "written to the block within the slab" sounds, as if there's one block for > one slab? > > > > If the new item is bigger than the size of any existing blocks, > > I thought all blocks are 1MB in their size? Should this be "of any existing > slab"? > > then a new slab is created, divided up into blocks of a suitable size. > > Again, I thought blocks are 1MB, then what is a suitable size here? > > If an existing slab with the right block size already exists, > > Confusing again. > > but there are no free blocks, a new slab is created. > > > In the second part of this documentation, the terms "page" and "chunk" are > used, but not related to "block". "block" is not used at all in the second > part. Can you clarify the meaning of block in this > context and create a link to slab, page and chunk? > > Btw, I found "Slabs, Pages, Chunks and Memcached" ([1]) really well written > and easy to understand. Would say this explanation is complete?
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. -Dormando
