Pertaining to memcached
Thu, 24 Jul 2003 12:44:08 -0700 (PDT)
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.