Yeah I looked over the code, I'm pretty sure you're right. I kind of forget my original rationale for posting this, I think we were trying to figure out why we were able to allocate large objects after we had thought to have already filled up the cache. Anyway I don't have access to enough historical information to make any valid points :) Thanks for responding, though.
Chris Eberly On Nov 14, 2007 9:39 AM, Chris Eberly <[EMAIL PROTECTED]> 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 > > > > >
