Pertaining to memcached

[Brad Fitzpatrick]

Nobody's really used the PHP API yet.  The Perl one has seen all the
battle-testing.  Also, we have two reports now that non-epoll is kinda
flaky, but in both cases I think the binary was built wrong.

Which version of libevent did you use?

I've never seen a kernel not free memory on process termination.  Sure
you're looking at the right number?

Were you swapping, btw?



On Thu, 24 Jul 2003, plix devil wrote:

>     I recently installed memcached for the purpose of testing it with
> the PHP API.  Upon starting the daemon things went well for the first
> connection, but after which it failed to respond (disconnect_all() was
> called before the script terminated).  I tried restarting the daemon and
> it worked again, but only for the first page load / connection.  I was
> wondering what the cause of this might be (running it in the foreground
> in verbose mode and the PHP client in debug mode didn't produce anything
> - I do believe, however, that the socket_connect() call was hanging [the
> PHP API is poorly written in this regard as socket_connect() doesn't
> timeout and hangs the script indefinitely])?  I do believe the problem
> to be with memcached, though I'm not sure how (maybe it's not properly
> terminating connections, but then again one dead connection wouldn't
> fill the pool).
>
>     Another problem that popped up was that when I killed the daemon
> manually (there was no documented way of doing it otherwise) it failed
> to free the memory so now the server has all of it's physical memory
> tied up in cache for a process that isn't running.  I'm not sure the
> cause of this, but a quick glance at the memcached code didn't reveal
> any signal-handling code to me (freeing the memory on process
> termination is still the kernel's job, but it appears to have failed in
> this respect - I'm running a RedHat 2.4.18 kernel on this particular
> machine without epoll).
>
>     Any insight into this would be greatly appreciated.
>
>     .plix
>