Werner you never mentioned which version of memcache you're using. For what it's worth, it seems things differ between 1.4.0 and 1.2.6. (Haven't peeked at 1.3.x series.)
1.2.6 will allocate a new slab if memory is available, before grabbing the last item off the free list (which may or may not have expired.) 1.4.0 will look for an expired object off the free list (last 50 items), before performing the above allocate-then-evict logic. The behavior of 1.2.6 results in the full slab allocation very quickly, which is the problem you are talking about. I suspect things are much better in 1.4.0, though of course over time you may still run out of slabs and need to restart servers in order to get a more optimal balance. Your other option is to compile with ALLOW_SLABS_REASSIGN and then right a cron/daemon which uses the memcache evicts and maxage stats to attempt to dynamically rebalance the pool, automating the one-at-a-time "slabs reassign" behavior to make it more effective. Mike On Thu, Jul 23, 2009 at 06:42, dl4ner<dl4...@gmail.com> wrote: > > Hi, > >> The thing is that we use a linked list to store all of the items in. >> Every time a user tries to use an item (get / set / incr etc), the >> item will be moved to the beginning of the linked list. Whenever you >> try to insert an item in the cache, the first thing we will do is to >> look in the tail of the linked list to see if we have any expired >> items (we will only look at 50 items). If we don't find any expired >> items there, we will try to allocate memory. If the allocation fails, >> we will return to the linked list and evict an object from the tail. > > thanks for explanation. > > Cheers, > > Werner.
