On Monday, October 7, 2013 12:14:52 AM UTC-4, Dormando wrote:
>
> Is memcached handling any traffic at all when you see it in this state? If
> you strace it is it still reading/writing/anything happening?
>
memcached isn't deadlocked at this point, as a small number of connections
seem to con
memcached.c appears to disable SO_LINGER
...
&ling = {0, 0};
error = setsockopt(sfd, SOL_SOCKET, SO_LINGER, (void *)&ling,
sizeof(ling));
...
--
---
You received this message because you are subscribed to the Google Groups
"memcached" group.
To unsubscribe from this gro
I tried running the mc_conn_tester script, but wasn't able to trigger the
problem with that.
The interesting thing is that even if I close down all apps that are
communicating with memcached, eg. Apache (due to the pecl memcached
modules), the memcached daemon still has thousands of CLOSE_WAIT
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.
I've been monitoring memcached over the past few days, and it no
On Monday, September 30, 2013 12:23:42 PM UTC-4, LesMikesell wrote:
>
> That sounds like your client is opening persistent connections but not
> reusing them.
Doesn't the CLOSE_WAIT state indicate that the client has sent a FIN and
yet memcached hasn't internally closed/cleaned up the connec
Using memcached 1.4.15
Over the past few months I've been having a few issue with memcached,
notably the issue here:
http://code.google.com/p/memcached/issues/detail?id=260
However, another, maybe related issue, is that once every few days, clients
(websites running PHP) cannot connect to th
