Steve Chu wrote:
Is there a need that we set "-m 1800", so we leave 248MB for connections. so, when the memcached reaches limit(here 1800) and starts to free items, we still can connect to it?
Yes, that's a reasonable approach. Unfortunately, it's hard to pinpoint exactly how much memory each connection needs without looking at your application. One place where memory usage varies is in the command input buffering. If a client sends a huge multi-key "get" command, memcached needs to allocate enough buffer space to hold the entire command before parsing it. (This doesn't apply to "set" commands; the item data doesn't use any temporary buffers.) So if your application rarely requests a bunch of items at once, you will be able to make do with less memory per connection.
But obviously given that the failure behavior is unpleasant, you should be conservative in your estimates.
Is -m option for slabs not for malloc?
At the moment, yes, -m only sets the maximum size of the cache itself, not any of the other data structures. Those are allocated as needed.
Changing the code to make -m apply to the whole application, not just the cache, was one of the proposed projects at the first memcached hackathon, but nobody took it up. Maybe at the next one someone will scratch this particular itch; I agree it would be much nicer to be able to set a fixed limit on memcached's memory usage regardless of what the memory is used for.
-Steve
