[memcached] bradfitz, r288: merge all trunk changes since tag
brad at danga.com
Tue May 30 19:21:46 UTC 2006
I believe I #ifdef'ed it out for now. I understand your approach... I'll
make it a runtime option probably.
On Tue, 30 May 2006, Steven Grimm wrote:
> Brad Fitzpatrick wrote:
> > Modified: branches/facebook/ChangeLog
> > ...
> > + * Brad Fitzpatrick <brad at danga.com>: allocate 1 slab per class
> > + on start-up, to avoid confusing users with out-of-memory errors
> > + later. this is 18 MB of allocation on start, unless max memory
> > + allowed with -m is lower, in which case only the smaller slab
> > + classes are allocated.
> That shouldn't be necessary any more if you're starting from the
> Facebook version of the code; I changed slabs.c so that it never gets
> those out-of-memory errors (at the cost of exceeding the maximum memory
> setting if you fill up your cache before you've allocated a slab of a
> particular class).
> Unfortunately preallocation doesn't play too well with the
> powers-of-less-than-2 slab allocation strategy, because if your slab
> class growth factor is low, you will end up with a hundred or more slab
> classes, and thus potentially a fair amount of wasted memory if you
> don't end up using all of them. That's why we went with our on-demand model.
> At the very least I think there should be a command-line switch to
> disable this for people who have fixed-size values and thus will only
> ever use one slab class. I don't think it should be left as a
> compile-time option because (using Facebook as an example) some of the
> memcached instances at a site can use fixed-size items while others
> don't, and having to keep track of two separate binaries isn't fun.
More information about the memcached