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 <[EMAIL PROTECTED]> 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 >>
