You'll run into a few problems... -m 1 won't work the way you think since it'll force-allocate one slab page per slab class. we don't have a fallback mode to cut that down.
We also don't do anything to detune the thread stack size (which is probably 2mb still?), plus a handful of allocations around each worker thread (the new event base, connection buffers, etc). That still seems sort of high, but thread stacks + etc would account for quite a bit of it. You can also try reducing the size of the hash table.. that could show up as VSZ if you haven't written anything into it yet. On Mon, 27 Apr 2015, Hans Kramer wrote: > Hi, > I am using memcached on a system with very modest RAM: 64Mb to be precise (an > Artila Matrix 504). > I have specified -M 1 -t 1 to reduce the memory allocated by memcached. > Now RSS is always modest and around an explainable value, however, VSZ is at > least 20Mb and with every > thread I add VSZ increases with at least 6 Mbytes. If I understand this > correctly, this relative "high" VSZ, increases the oom_score > a lot. Hence I would like to reduce unnecessary alloc as much as possible. > I have briefly looked at the memcached source and I cannot any significant > mallocs. Is this perhaps coming from the libevent > library? > > Any insights will be helpful. > > Kind regards > > Hans > > -- > > --- > You received this message because you are subscribed to the Google Groups > "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > >
