Re: Thousands of CLOSE_WAIT connections
On Mon, Sep 30, 2013 at 10:36 AM, Nic Jansma nicjan...@gmail.com wrote: ... The rest of the connections are in FIN_WAIT1, ESTABLISHED, etc, but the vast majority are the ~4,000 CLOSE_WAIT connections. I'm going to try bumping up the connection limit to 32k to avoid this for now, but clearly there's something going on where memcached isn't closing connections. That sounds like your client is opening persistent connections but not reusing them. -- Les Mikesell lesmikes...@gmail.com -- --- 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 memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Thousands of CLOSE_WAIT connections
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 connection? I don't fully understand how pecl memcache/memcached's persistent connections feature uses the socket, but I don't imagine they would send a FIN then still try to re-use the connection later. - Nic -- --- 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 memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Memcached expiration vs eviction
I am working with this Memcached cluster which reports about 70% of the objects put in end up being evicted. I have a TTL of 1 hr for all objects I put in. Looking at my hit/miss metrics I've realized that in time my hit rate has got much better while evictions increase. Misses have increased at a very slow rate compared to my hit rate increase. From the bytes written stat I know that I'd need about 5 times more Memcached capacity to hold of the bytes I place in Memcached today. But given my hit rate success I don't think it makes sense to me to increase my Memcached capacity 5 times. I'm guessing that allowing my cache to discard data based on evictions rather than expirations is a lot more cost effective as long as the hit rate doesn't get affected. I'd like to know, how much more expensive is for Memcached to perform evictions rather than expirations? Is there any other major negative effect I should take in account about relying on evictions such as thread contention during the eviction process or something else that could affect my app's performance? One more thing, I see some entries in my memcached.log but they don't have a time stamp which makes it very difficult to tie those entries back to my app logs and all the other logs. Is there a way to configure Memcached to log timestamps along with each message? Claudio -- --- 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 memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Issue 344 in memcached: GET immediately after SET fails with ERROR when the values is empty
Comment #1 on issue 344 by jensge...@hotmail.com: GET immediately after SET fails with ERROR when the values is empty http://code.google.com/p/memcached/issues/detail?id=344 Sorry, but PEBKAC. Of course the SET requires an (in this case empty) data line. = How can I close the issue as invalid? -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- --- 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 memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
