On Thu, Oct 3, 2013 at 4:50 PM, Nic Jansma <[email protected]> wrote:
> I don't think the problem is caused by the PHP extension at this point,
> since having the sockets in a CLOSE_WAIT state is most likely indicative of
> something in the memcached server not closing the connection after it gets a
> FIN.
>
The send/receive sides of a socket are closed separately. The
client's FIN means it isn't going to send any more. That's almost
unrelated to the server having to finish sending the requested data
before closing it's side. It can very well be that the client isn't
reading the response it requested and your tcp window is full as the
server tries to send.
> I've been monitoring memcached over the past few days, and it normally
> doesn't get in this state. i.e. I don't normally see ANY CLOSE_WAIT
> connections open.
>
> However, when it starts not responding to connection requests, it appears to
> be in this state where there's thousands of CLOSE_WAIT connections.
You have a finite number of sockets.
> Does anyone have suggestions for how I can debug this further? Memcached is
> not being production-ready reliable for me right now (including the weekly
> crash listed in the original post, which may or may not be related).
Lots of people are using various versions of the server in production.
Can you try to reproduce the behavior with some other client or
benchmark/load test tool? My guess is that it is something unrelated
in the code calling the client library that can cause it to request
but not consume the response.
--
Les Mikesell
[email protected]
--
---
You received this message because you are subscribed to the Google Groups
"memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
