Evictions with Free Space

[NerdyNick]

I'm not sure if this was a bug fixed in later versions, which if so
will allow me to push for updating the version, but with v1.2.2 of
memcached was there a reason why there always appears to be ~100MB
free and evictions happening.

--
Nick Verbeck - NerdyNick
----------------------------------------------------

[Artur Ejsmont]

100mb free is across entire slabs set i assume. If so its not a bug.
You have some slabs full and some not. If you have a lot of activity
on particular slab size it will cause evictions even that other sizes
are sitting around half empty.

Art

--
Visit me at:
http://artur.ejsmont.org/blog/

[Adam Lee]

It's not a bug-- in order to be speed up memory management, memcached uses what is known as a slab allocator instead of using standard malloc()/free()

Basically, it only allocates memory in blocks of 1MB (by default), referred to as a slab.  Slabs belong to a slab class, which is defined by the size of item that is stored in that slab. For ease of explanation, let's say you have only two slab classes, a slab class at 1k and the next slab class at 2k (though in reality the default growth factor in slab classes is 1.25 and there are a bunch of them).  An item of 800b would get put into a slab in the 1k slab class and an item of 1024b, 1.5k, 1.99k or 2k would get put into a chunk in the 2k slab class.

When an item is stored, first there is a check to see which class it should get shoved in, based on its size, and then mc will check that class's stack to see if there are any empty spots available.  If not, mc will attempt to allocate a new slab for that class and store the item there.

All of this means, obviously, that there is some tradeoff in unused memory-- not every item is going to be exactly the size defined by the slab class, or you could have just one item stored in a class for items of size 1k, meaning that 1MB is allocated just to store that 1k item-- but it is more than made up for by the fact that all of these operations are very fast and very simple.  It just examines a stack and does some very simple multiplication and pointer arithmetic to find/store any item and slabs never have to be free()ed, mc just puts that spot back in the empty stack and it'll eventually get reused by another item looking to go into that slab class.

There are lots of different configuration options that can change this behavior, as I've hinted at-- you can change the growth factor, the slab size, you can ask memcached to allocate all of the memory at startup instead of lazily allocating slabs only as they're needed, and you can actually even compile memcached to use malloc() if you want.

Anyway, the slab allocator is worth learning a little bit about if you're going to be doing anything more than very tangential work to memcached.

Just googled around a bit and found this, which might be a decent place to start:

http://code.google.com/p/memcached/wiki/MemcachedSlabAllocator#What's_a_clsid?

Hope that helps!

--

awl