Redis Clients Handling

This document provides information on how to Redis handles clients from the point of view of the network layer:connection s, timeouts, buffers, and other similar topics is covered here.

The information contained in this document is a applicable to Redis version 2.6 or greater.

How client connections is accepted

Redis accepts clients connections on the configured listening TCP ports and on the Unix socket if enabled. When a new client connection was accepted the following operations is performed:

• The client socket is a put in non-blocking state since Redis uses multiplexing and non-blocking I/O.
• The option is set on order to ensure that we don't have delays in our TCP_NODELAY connection.
• A readable file event is created so, Redis is able to collect the client queries as soon as new data is avail Able to is read on the socket.

After the client is a initialized, Redis checks if we are already at the limit of the number of clients then it is possible To handle simultaneously (the configured using maxclients the configuration directive, see the next sections of this Documen T for further information).

In case it can ' t accept the current client because the maximum number of clients is already accepted, Redis tries to send An error to the client in order to make it aware of this condition, and closes the connection immediately. The error message would be able to reach the client even if the connection is closed immediately by Redis because the new s Ocket output buffer is usually big enough to contain the error, so the kernel would handle the transmission of the error.

In what order clients is served

The order is determined by a combination of the client socket file descriptor number and order in which the kernel reports Events, so the order was to be considered as unspecified.

However Redis does the following and things when serving clients:

• It performs a single read() system call every time there is something new to read from the client socket, in order to Ensure that if we have multiple clients connected, and a few is very demanding clients sending queries at the high rate, O Ther clients is not penalized and would not be experience a bad latency figure.
• However once new data is read from a client, and all of the queries contained in the current buffers is processed sequentially. This improves locality and does is need iterating a second time to see if there is clients that need some processing Tim E.

Maximum Number of clients

In Redis 2.4 There is an hard-coded limit is about the maximum number of clients that is possible to handle simultaneously.

In Redis 2.6 This limit was dynamic:by default is set to 10000 clients, unless otherwise stated by the maxclients directive in Redis.conf.

However Redis checks with the kernel, the maximum number of the file descriptors that we were able to open (thesoft Limit is checked), if the limit is smaller than the maximum number of clients we want to handle, plus Number of file descriptors Redis reserves for internal uses) and then the number of maximum clients are modified by Redis to Match the amount of clients we is really able to handle under the current operating system limit.

When the configured number of maximum clients can isn't honored, the condition is logged at startup as in the following E Xample:

$ ./redis-server --maxclients 100000[41422] 23 Jan 11:28:33.179 # Unable to set the max number of files limit to 100032 (Invalid argument), setting the max clients configuration to 10112.

When Redis was configured in order to handle a specific number of clients it was a good idea to make sure that the operating System limit to the maximum number of file descriptors per process is also set accordingly.

Under Linux These limits can is set both in the current session and as a system-wide setting with the following commands:

• ULIMIT-SN 100000 # This would only work if hard limit is big enough.
• Sysctl-w fs.file-max=100000

Output Buffers Limits

Redis needs to handle a variable-length output buffer for every client, since a command can produce a big amount of data t Hat needs to being transferred to the client.

However it is possible, a client sends more commands producing, output to serve at a faster, at which Redis CA n Send the existing output to the client. This is especially true with PUB/SUB clients-a client is not able to process new messages fast enough.

Both the conditions would cause the client output buffer to grow and consume more and more memory. For this reason by default Redis sets limits to the output buffer size for different kind of clients. When the limit is reached the client connection are closed and the event logged in the Redis log file.

There is kind of limits Redis uses:

• The hard limit was a fixed limit that when reached would make Redis closing the client connection as soon as Possib Le.
• The soft limit instead is a limit this depends on the time, for instance a soft limit of megabytes per ten Seco NDS means that if the client have an output of buffer bigger than megabytes for, continuously, seconds, the connection G ETS closed.

Different kind of clients have Different default limits:

• Normal Clients has a default limit of 0, that is means, no limit at all, because most Normal clients use blocking I Mplementations sending a single command and waiting for the reply to be completely read before sending the next command, s O It is always not desirable to close the connection in case of a normal client.
• pub/sub Clients has a default hard limit of megabytes and a soft limit of 8 megabytes per seconds.
• Slaves has a default hard limit of megabytes and a soft limit of megabyte per second.

It is possible to change the limit at runtime using the CONFIG SET command or in a permanent using the Redis Configura tion file redis.conf . See the example in the Redis distribution for more information on how to redis.conf set the limit.

Query Buffer Hard Limit

Every client is also subject to a query buffer limit. This was a non-configurable hard limit that would close the connection when the client query buffer (which is the the buffer we U Se to accumulate commands from the client) reaches 1 GB, and was actually only a extreme limit to avoid a server crash in Case of client or server software bugs.

Client Timeouts

By default recent versions of Redis don ' t close the connection with the client if the client is an idle for many seconds:the Connection'll remain open forever.

However if you don't like this behavior and you can configure a timeout and so if the client is idle for more than the spec ified number of seconds, the client connection would be closed.

You can configure the this limit via redis.conf or simply using CONFIG SET timeout <value> .

Note that the timeout is applies to number clients and it does not apply to PUB/SUB clients, since a pub/sub co Nnection is a push style connection so a client this is an idle is the norm.

Even if by default connections is not subject to timeout, there is both conditions when it makes sense to set a timeout:

• Mission critical applications where a bug in the client software could saturate the Redis server with idle connections, Caus ing service disruption.
• As a debugging mechanism in order to being able to connect with the server if a bug in the client software saturates the Serv Er with idle connections, making it impossible-interact with the server.

Timeouts is not to being considered very precise:redis avoids to set timer events or to run O (N) algorithms in order to Check idle clients, so the check is performed incrementally by time to time. This means, which is possible, and the timeout is set to ten seconds, the client connection would be a closed, for Inst Ance, after seconds if many clients is connected at the same time.

CLIENT command

The Redis Client command allows to inspect the state of every connected client, to kill a specific client, to set names to Connections. It is a very powerful debugging tool if you use the Redis at scale.

CLIENT list is used on order to obtain a LIST of connected clients and their state:

redis 127.0.0.1:6379> client listaddr=127.0.0.1:52555 fd=5 name= age=855 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=clientaddr=127.0.0.1:52787 fd=6 name= age=6 idle=5 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping

In the above example session, the clients is connected to the Redis server. The meaning of a few of the most interesting are the following:

• addr: The client address, that's, the client IP and the remote port number it used to connect with the Redis ser Ver.
• FD: The client socket file descriptor number.
• name: The client name as set by client SETNAME.
• Age: The number of seconds the connection existed for.
• Idle: The number of seconds the connection is idle.
• flags: The kind of the client (N means normal client, check the full list of flags).
• Omem: The amount of memory used by the client for the output buffer.
• cmd: The last executed command.

See the CLIENT list documentation for the full LIST of fields and their meaning.

Once You has the list of clients, you can easily close the connection with a client using the client KILL command specify ing the client address as argument.

The commands client SETNAME and client GETNAME can be used to set and get the connection name.

Http://redis.io/topics/clients

Redis Clients Handling