Hi Les, On Sat, Mar 13, 2010 at 12:29 AM, Les Mikesell <[email protected]>wrote:
> On 3/12/2010 5:10 PM, Martin Grotzke wrote: > >> With my question "how do I have to run memcached to 'store' these >> sessions in memcached" I was not referring to a general approach, but I >> was referring to the concrete memcached options (e.g. -n 204800 for >> 200kb slabs) to use. >> >> The post you mentioned is very high level and does not answer my >> question. For this you should go into a little more depth. >> > > 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? > > But it's still not very clear how much extra you need to make sure that the > hash to a server/slab will always find free space instead of evicting > something even though space is available elsewhere. > What are you meaning with "hash to a server/slab"? I'm selecting the memcached node an item goes to manually btw, without hashing. The selected memcached node is stored in a cookie, so that I know where to get my session from. Btw: my sessions are stored only for backup in memcached, they're still kept in local memory for normal operations (see [2] for more details). Regarding the extra space: asume we have a minimum space allocated for key+value+flags of 1mb. Then I have only a single slab class and each chunk is going to take 1mb. So I'd know that I could "store" <total memory> / 1mb items (item here is key+value+flags) in memcached (e.g. with 1gb, I could store 1000 items). Is there s.th. missing? Thanx && cheers, Martin [1] http://www.mikeperham.com/2009/06/22/slabs-pages-chunks-and-memcached/ [2] http://code.google.com/p/memcached-session-manager/ <http://www.mikeperham.com/2009/06/22/slabs-pages-chunks-and-memcached/> > > -- > Les Mikesell > [email protected] > -- Martin Grotzke http://www.javakaffee.de/blog/
