Max value for timeout

[chilumb...@gmail.com]

Is there a max value for the timeout param in redis? The default value is =0, which means timeouts are disabled and connections remain open and continue to increase significantly. 

Along with the default timeout value of =0, i have the tcp-keepalive set to 60. However, when i run "redis-cli info stats", the total_connection_received is over 7 million. My understanding of the tcp-keepalive was that even if connection timeout is disabled, the tcp-keepalive will disconnect any idle connections after a specified time. Also, since the timeout is disabled, that means the total_connections_received are not just a counter of all connections since the server restarted, but also currently open connections right?

[Greg Andrews]

total_connections_received is going to be an incrementing value.  If I understand correctly what you want (to know how many connections exist when you issue the INFO command), then total_connections_received is going to be useless for you.  You don't know how many of them are current connections and how many were open in the past and closed.  As I said in the other thread, you want to watch the connected_clients value.

I'm afraid you're mistaken about how TCP keepalives work.  They do not cause disconnections.  In fact, they are designed to do the opposite: prevent disconnections.  TCP keepalives are one mechanism that makes TCP packets pass from the client machine to the server machine, even if the client software is sitting idle and not sending commands or getting responses.  When the connection must pass through network devices like routers or load balancers (and especially when the network device must translate the IP addresses between the machines), the network devices can notice the connection is idle (i.e., no packets are being exchanged between the two machines) and decide to break the connection.  TCP keepalives try to prevent this.  They try to prevent the network device(s) from disconnecting the idle sessions,

As a side effect, TCP keepalives can help detect when idle connections have been broken.  This is not causing disconnection.  It is detecting when disconnection has occurred for other reasons.

Finally, TCP keepalives do not prevent a client from closing its connection to the server.  Neither does setting timeout = 0 in the Redis server.  Only the settings in the client will prevent the client from calling close() on a connection to Redis.

  -Greg

On Tue, Nov 10, 2015 at 7:50 AM, <chilumb...@gmail.com> wrote:

Is there a max value for the timeout param in redis? The default value is =0, which means timeouts are disabled and connections remain open and continue to increase significantly. 

Along with the default timeout value of =0, i have the tcp-keepalive set to 60. However, when i run "redis-cli info stats", the total_connection_received is over 7 million. My understanding of the tcp-keepalive was that even if connection timeout is disabled, the tcp-keepalive will disconnect any idle connections after a specified time. Also, since the timeout is disabled, that means the total_connections_received are not just a counter of all connections since the server restarted, but also currently open connections right?

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
To post to this group, send email to redi...@googlegroups.com.
Visit this group at http://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.

[George Chilumbu]

Thanks for all the good info and clarification on my mis-understanding of the timeout and tcp-keepalive params.

What about the tcp-backlog; how does that affect connections between clients and the redis cluster,  or performance in general?

--
You received this message because you are subscribed to a topic in the Google Groups "Redis DB" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/redis-db/MPyJGBtmNCM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to redis-db+u...@googlegroups.com.

[George Chilumbu]

Hi Greg, i would like us to forget connections altogether. I might have run to the conclusion that connections are being closed carelessly. 

So here is really my issue; we are getting this error from predis:

    Error while reading line from the server. [tcp://10.0.0.1:6379]

And we are trying to pint point the cause of this error, and also determine whether it is an issue from the predis side, or redis cluster's side. 

Now this is what i am now considering as a potential issue. Maybe the way predis uses connections is leading to IP connection tracking on the server getting overloaded. But when i run this 

    $dmesg| grep conntrack

on the redis server, i get  [11351916.175115] nf_conntrack version 0.5.0 (16384 buckets, 65536 max). The ip_conntrack does not show that the table is full, or dropping of any packets. Would the result above still prove possible this can be causing the error above?

On Wed, Nov 11, 2015 at 2:27 AM, Greg Andrews <hva...@gmail.com> wrote:

--
You received this message because you are subscribed to a topic in the Google Groups "Redis DB" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/redis-db/MPyJGBtmNCM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to redis-db+u...@googlegroups.com.