Memory allocation default change (-m < 40 doesn't work)

[GoogleCodeExporter]

Yo,

The default way memcached allocates memory is a little broken right now. It
also stands for debate that there can be improvements to the defaults.
However since this is a potential default adjustment, I want to address the
community before we do anything.

The issue I'm working off of:

- '-m n' where n < number_of_slab_classes does not presently work.
When memory is requested for a slab class and there is none available
(either there is no memory at all in the slab class or it is out of space),
memcached allocates 1 page if there is free space available in the main
pool, *OR* will *always* allocate 1 page if the slab class has *0* pages
allocated to it. This latter part ignores the memory limit.

This means if you set -m 18, fill up one slab class, then put one item in
all the other slab classes, you will be using over 60 megs of ram. This
gets worse if you adjust the page size.

An option for dealing with this is to enable forced memory preallocation (1
page per slab) at start time and whine if there isn't enough memory.

The other side of this issue is that by default we allocate memory 1
megabyte at a time as pages are requested. So if you set '-m 8000' and
insert items very slowly with low expire times, you won't ever get to 8G.
This leads to users telling memcached to use more RAM than is available on
the box, and then grinding into swap after several days or weeks.

The -L option will preallocate the memory if you have hugetlbs/etc
available. If a mass allocation (one giant block) doesn't work, it falls
back to allocating one page at a time.

I've thought about this before, and Dustin just reiterated, that the
default should probably be to allocate all of the memory requested at start
time. It should attempt to do a mass allocation, and if that fails it
should spin on 1 meg allocations until it's full.

From there, the slabs should be preallocated with at least 1 page, since
the existing behavior will not work anymore.

However this is a pretty big change to the defaults. It should have a large
effect on the usability of memcached, so I want to propose that we bother
doing this in some form.

Thoughts? Please respond for discussion on the mailing list or in the issue
here.

(this won't be queued for or block 1.4.2, but could show in 1.4.3)

Original issue reported on code.google.com by dorma...@rydia.net on 7 Oct 2009 at 10:54

[GoogleCodeExporter]

My thoughts:
* Always allocate all memory from the system up front. This makes it easier for 
the
end user to see how much memory the server will use...

* If you specify a really low memory limit (so that you cannot satisfy 
preallocation
of a slab page to each slab class), disable the preallocation of memory into 
each
slab class. Remember to write out a warning to the user that preallocation was
disabled, so that he might get OOM when storing objects.

* If you specify a really high maximum item limit, preallocation of memory into 
all
of the different slab classes will eat up _a lot_ of memory (20G if you set 
-I100m),
so I think we should disable preallocation of memory if it consumes more than 
lets
say 20% of the total memory you gave memcached. (and we should of course warn 
the
user)... Why? I believe that most of the objects stored in memcached will most 
likely
be relatively equal in size (with some exceptions). 

Original comment by trond.no...@gmail.com on 30 Oct 2009 at 7:36

[GoogleCodeExporter]

Trond's first two points mostly reiterate what I said.

I think on the third point... if a user has adjusted -I to be a high number, 
and the
prealloc would take over a certain watermark of the memory limit, disable 
prealloc...

I played with some numbers and I can see plenty of situations where people can 
gum
themselve sup on it.

In the future the slab handler will be better about large items, I think. In the
short term, the safest thing for us to do is disable the alloc reservation (but
otherwise prealloc memory) if you've raised the -I default at all. Lowering it 
should
not cause this. This should give the user a more deterministic behavior and 
easier to
understand constraints.

So unless someone complaints in the next hour I'll implement just that :)

Original comment by dorma...@rydia.net on 31 Oct 2009 at 12:03

[GoogleCodeExporter]

killing this. plans are going elsewhere anyway.

Original comment by dorma...@rydia.net on 7 Dec 2011 at 11:50

• Changed state: Invalid