Proposal: lets get rid of the non-thread code
Dirk-Willem van Gulik
dirkx at webweaving.org
Fri Feb 8 14:22:12 UTC 2008
On Feb 7, 2008, at 9:30 PM, dormando wrote:
>> Has anyone compared it to running as many separate non-threaded
>> instances as you have processors?
> That's how it was done originally. The idea of threading it is to
> get greater memory efficiency, and higher efficiency of multi-get
> requests. IE; box has 64G of RAM, but you'll peg a single CPU before
> using all of it, but your code does tons of mgets and it sucks a bit
> to poll multiple memcached's for the data.
My experience though is that, multithreaded, on Solaris/FreeBSD/Linux
it will comsume some around 5, 10 and 30% more CPU than when running
as multiple thread v.s. single thread/process. And that having
multiple processes or simply start multiple works fine on dual cpu
dual core sort of levels. And when you fork or start more things split
nicely*. In reality I've not seen this matter that much - as you
generally try to keep 30-50% capacity overshoot on each memcached
dedicated box in case one of the other(s) fails.
Not sure what happens on 8+ cores -- but given the cost of bandwidth
to memory and the PCI card IO - propably not that relevant. (Esp. on
linux where the interrupts from the PCI card can peg things
essentially on one CPU).
So I'd only do this if you where very sure it was as good in virtually
all cases and better in some. Which is something I've certainly not
yet seen that clearly.
*: except when you see some core affinitiy propably due to the IRQ
beeing handled there.
More information about the memcached