memcached crashing
Brad Fitzpatrick
brad@danga.com
Tue, 29 Jun 2004 21:10:53 -0700 (PDT)
Do *not* use libevent's rtsig support. I thought he removed that given
how buggy it was. Three really smart people worked on it for quite some
time without getting it anywhere near reliable. It's just a crap
interface and it was never made to work with libevent.
Use poll if you must, but epoll's really the best.
- Brad
On Wed, 30 Jun 2004, Jon Valvatne wrote:
> Hello,
>
> I've been using memcached to add some caching to a production system to
> speed things up. Everything worked smoothly on my test box, but I ran
> into nothing but problems when trying to go live with the changes:
> Memcached would just die randomly, without any error message whatsoever,
> within minutes of startup. And even while it was running and accepting
> some connections, other connections appeared to be randomly refused.
>
> The only difference between the test box and the production system is
> that one is running Fedora Core 2, and the other Redhat 9. Before I try
> to debug the situation more, I would like to ask: Does anyone here have
> any experience running memcached with Redhat 9? There's obviously no
> epoll support, so I compiled the latest libevent with --with-rtsig, and
> I'm assuming that's what memcached is using. Is this just inherently
> buggy, or so poor-performing that my system with about a hundred
> connections and several operations per second will cause the problem I'm
> seeing?
>
> One thing that worried me were the test results when compiling libevent:
>
> Running tests:
> KQUEUE
> Skipping test
> POLL
> test-eof: OKAY
> test-weof: OKAY
> test-time: OKAY
> regress: FAILED
> SELECT
> test-eof: OKAY
> test-weof: OKAY
> test-time: OKAY
> regress: FAILED
> RTSIG
> test-eof: OKAY
> test-weof: OKAY
> test-time: OKAY
> regress: FAILED
> EPOLL
> Skipping test
>
> What are these regress tests, and what would cause them to fail?
>
> By the way: Is there any way to ask memcached or libevent which polling
> mechanism is being used?
>
> Thanks in advance,
>
> Jon Valvatne
>
>