I wouldn't recommend anyone use the ALLOW_SLABS_REASSIGN code as it is - it is unproven and we probably should have removed it a long time ago. It'll come back as a proper implementation soon enough.
-Dormando On Tue, 28 Jul 2009, Mike Lambert wrote: > > 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<[email protected]> 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. >
