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

[dormando]

Yeah. If you squint at it you'll see that specific check isn't dependent
on memory being freed out of the LRU at all, it's strictly comparing the
mem_limit vs the total amount of memory allocated from the OS already.
MC never releases memory back to the OS, so the mem_malloc'ed number only
ever grows when the slabber is enabled.

Again, unless I'm wrong!

-Dormando

Chris Eberly wrote:
> ( 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 rydia.net> 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
>>