Memory management

[Steven Grimm]

Moving objects around in memory would naturally have a CPU cost. And if 
your memcached was otherwise fully consuming the available processor(s), 
then something would have to give: either you'd slow down request 
processing to allow time for the necessary repacking, or you'd reduce 
memory efficiency by allowing fragmentation to start happening.

On the other hand, if you're maxing out your CPU with a memcached 
instance, you have bigger problems to deal with; chances are you are 
already falling behind on your request processing anyway.

But I don't think that's going to be too common. As a sample data point, 
as I write this, one of our typical memcached instances is serving about 
37,000 requests a second and is eating under 20% of the CPU capacity of 
the 4-core box it's running on. That's a LOT of headroom you could use 
to shuffle memory around. Obviously other sites could be running 
memcached on slower hardware, or with higher request volumes, and thus 
have less CPU time to spare, but there will probably be at least a 
little wiggle room. (And in fact I suspect we're probably on the high 
end of the scale in terms of memcached traffic; we did the 
multithreading work for a reason!)

-Steve


Jure Petrovic wrote:
> Yes, I've noticed that when "memcached -vv" showed totally 
> different slab classes than it should according to 
> Brad Fitzpatrick's "Distributed caching with Memcached."
>
> Do you think that packing memory would not be a problem
> performance-wise? What if the system is under constant (heavy)
> load? 
>
> >From what I've seen, memory utilization is very good. Especially,
> if you don't have to manage (pack) it, knowing it just won't 
> get fragmented beyond certain point.
>
> Thank you, Steven, for theral explanation :-)
> Jure
>
>