Allocating memory beyond mem_limit if p->slabs <= 0

Chris Eberly chris.eberly at
Wed Nov 14 17:39:18 UTC 2007

( No one has responded :) )

I agree with the first part of your response, it does allow you to
allocate a slab of every size regardless of the malloc limit. I might
be misunderstanding the code as well, but in this function we are
already past the point of checking the LRU, we are simply deciding
whether we can allocate a new slab or not. Anyhow, the first statement
is a good rationale for this code, and it hardly matters for the large
memory installations most people seem to be using. I'm new to the
source code so I'm just double checking my assumptions about the
design decisions. Thanks!

Chris Eberly

On Nov 14, 2007 12:06 AM, dormando <dormando at> wrote:
> (Has anyone responded to this?)
> It's my understanding (although I could be wrong, this code's just a little
> dicey), that if you're not pre-allocating your slabs, that fix prevented
> transient out of memory errors if you hit the malloc limit before having
> one slab of every size available.
> Since that's counting the malloc'ed memory and not the "used" memory, you'd
> otherwise end up stuck having OOM errors on every store of an item of
> specific size, even if there's plenty of room in in the LRU. Which there
> always is unless you run memcached with the -M option.
> -Dormando
> Chris Eberly wrote:
> > Hello,
> > We are working on optimizing our memcached configuration and I came
> > across something I don't understand. It seems as though you are able to
> > allocate a slab (and therefore more memory) even if you have passed the
> > command line memory limit with other slabs. The code in question is in
> > slabs.c in do_slabs_newslab():
> >
> >     if (mem_limit && mem_malloced + len > mem_limit && p->slabs > 0)
> >         return 0;
> >
> > So I can theoretically allocate 1 of each type of slab I don't have yet
> > even if I am passed my memory limit. While it turns out this is
> > advantageous (or at worst irrelevant because of the scale of the memory
> > we are using), I am wondering what the rationale behind this code is?
> >
> >
> > Chris Eberly

More information about the memcached mailing list