[memcached] bradfitz, r288: merge all trunk changes since tag 1.1.12... (fwd)

Steven Grimm sgrimm at facebook.com
Tue May 30 19:15:48 UTC 2006

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 mailing list