memcached performance on Mac OS 10.4

Peter Bengtson peter at
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  
> panics.
> So...
> 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

still reports:

	[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 mailing list