memcached performance on Mac OS 10.4
peter at peterbengtson.com
Sun Jan 15 16:43:36 UTC 2006
I'm experiencing the previously reported 200 ms latency on each
memcached query. As five queries per second is far, far worse than
scrapping memcache altogether and running without memory caching, I
was wondering if the problems on Mac OS 10.4 have been addressed and/
or worked around in any way since Gregory Block wrote the following
to this list in March last year:
> I had a bug open on Radar regarding memcached causing core dumps when
> used in poll(), kevent(), or anything other than select. I've been
> informed by the team that there's a fix in place for Tiger, and that
> they've tested under tiger and poll() without seeing the kernel
> Until that fix is in place, it's memcached + select() on mac os x, or
> watch your kernel go tits up.
Of course, libevent since v1.1 has a "workaround", but memcache when
using libevent 1.1a and started in the following fashion:
/usr/local/bin/memcached -k -uroot
[warn] kq_init: detected broken kqueue; not using.: Bad file descriptor
and then proceeds to respond exactly five times a second.
Also, James Robinson wrote, on Aug 30:
> stores of payload between 14000 and 195846 bytes all happen on OS X
> without delay. Apparently OS X's TCP_NOPUSH is just plain busted, as
> seems to be the net wisdom garnered from google.
So, I'm wondering what is happening here. Are the Mac OS 10.4
implementations of kqueue and TCP_NOPUSH still broken? Are there any
patches from Apple or any third-party solutions? And is the slow
speed we're seeing the result of select() being inherently slow on
Mac OS X? Is there another way of forcing memcached use poll()?
/ Peter Bengtson
More information about the memcached