[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.
-Steve
More information about the memcached
mailing list