sgrimm at facebook.com
Tue Mar 27 22:46:47 UTC 2007
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!)
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)
> >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 :-)
More information about the memcached