We're using Docker containers and there are lots of containers connect to MC in the same machine ( make a bit harder to debug).
And the output of secs_since_last_cmd shed me some lights on debugging. eg 4975273s ~= lifetime of a container. after killing that container, the curr_connections dropped. Question: Do we have any best practices to avoid this situation? eg, if we use `spymemcached` need to call `shutdown` ( or similar method) to close connection? or properly set `idle timeout` at server side or `timeout` at client side? Regards, Van On Monday, November 6, 2017 at 4:23:29 PM UTC+7, Dormando wrote: > > I'm not really sure what's happening. "conn_read" means the connection is > open and waiting for a read. secs_since_last_cmd shows those connections > haven't been hit in 20,000+ seconds. > > The most recent output are the listening sockets (:11211 stuff), so that's > normal. > > Does ss agree about there not being any connections? lsof? (dunno what OS > you're on). Could be an OS bug. Version is oldish but no bug I know of > like that has been found. > > On Mon, 6 Nov 2017, Mocking Bird wrote: > > > and the output of `stats conns` > > > > STAT 26:secs_since_last_cmd 4975273 > > STAT 27:addr tcp6:[::]:11211 > > STAT 27:state conn_listening > > STAT 27:secs_since_last_cmd 4975273 > > STAT 28:addr udp:0.0.0.0:11211 > > STAT 28:state conn_read > > STAT 28:secs_since_last_cmd 4975273 > > STAT 29:addr udp:0.0.0.0:11211 > > STAT 29:state conn_read > > STAT 29:secs_since_last_cmd 4975273 > > STAT 30:addr udp:0.0.0.0:11211 > > STAT 30:state conn_read > > STAT 30:secs_since_last_cmd 4975273 > > STAT 31:addr udp:0.0.0.0:11211 > > STAT 31:state conn_read > > STAT 31:secs_since_last_cmd 4975273 > > STAT 32:addr udp6:[::]:11211 > > STAT 32:state conn_read > > STAT 32:secs_since_last_cmd 4975273 > > STAT 33:addr udp6:[::]:11211 > > STAT 33:state conn_read > > STAT 33:secs_since_last_cmd 4975273 > > STAT 34:addr udp6:[::]:11211 > > STAT 34:state conn_read > > STAT 34:secs_since_last_cmd 4975273 > > STAT 35:addr udp6:[::]:11211 > > STAT 35:state conn_read > > > > > > > > On Monday, November 6, 2017 at 4:09:13 PM UTC+7, Mocking Bird wrote: > > > > Hi Dormando, > > I'm using > > memcached 1.4.25 > > > > and part of `stats conns` > > > > > > > > STAT 856:addr tcp:10.0.1.21:35202 > > STAT 856:state conn_read > > STAT 856:secs_since_last_cmd 20863 > > STAT 857:addr tcp:10.0.1.21:35208 > > STAT 857:state conn_read > > STAT 857:secs_since_last_cmd 20862 > > STAT 858:addr tcp:10.0.1.21:47728 > > STAT 858:state conn_read > > STAT 858:secs_since_last_cmd 17868 > > STAT 859:addr tcp:10.0.1.21:47734 > > STAT 859:state conn_read > > STAT 859:secs_since_last_cmd 17867 > > STAT 860:addr tcp:10.0.1.21:50138 > > STAT 860:state conn_read > > STAT 860:secs_since_last_cmd 17327 > > STAT 861:addr tcp:10.0.1.21:50146 > > STAT 861:state conn_read > > STAT 861:secs_since_last_cmd 17326 > > STAT 862:addr tcp:10.0.1.21:37065 > > STAT 862:state conn_read > > STAT 862:secs_since_last_cmd 13592 > > STAT 863:addr tcp:10.0.1.21:37072 > > STAT 863:state conn_read > > STAT 863:secs_since_last_cmd 13591 > > STAT 864:addr tcp:172.18.0.1:55552 > > STAT 864:state conn_parse_cmd > > > > > > I don't much understand the conns output. It's great if you can help > point out > > something interesting. > > > > Thanks, > > Van > > > > On Monday, November 6, 2017 at 3:57:08 PM UTC+7, Dormando wrote: > > What's the output of "stats conns" ? what's the exact version > you're > > on? > > > > On Mon, 6 Nov 2017, Mocking Bird wrote: > > > > > Hi, > > > > > > By using `stats` command, it's showing 800 connections but > netstat > > displays a few. > > > > > > see > > > ``` > > > echo stats | nc localhost 11211 | grep curr_ > > > STAT curr_connections 838 > > > > > > netstat -tn | grep 11211 | wc -l > > > 8 > > > ``` > > > > > > Here are my concerns > > > > > > + Why we see different results? > > > + From my monitor, curr_connections keeps growing. Any reason > why? > > > + Is there any way to reduce curr_connections safely ( vs > > restarting memcached)? > > > > > > > > > I'm using > > > memcached 1.4 > > > and java spymemcached > > > > > > Thanks, > > > Van > > > > > > -- > > > > > > --- > > > 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+...@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > > > > > > > > > -- > > > > --- > > 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+...@googlegroups.com <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > > > > -- --- 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/d/optout.
