Currently configuring Redis server as our backend caching service and during that wrote this post with some things to pay attention at in Redis config file.
Shortly enough but with links to other posts or documentation.
During that, the Redis server will send ACK-requests (Acknowledgment) after seconds from this parameter to keep a session alive:
...
tcp-keepalive 300
...
127.0.0.1:6389> CONFIG GET tcp-keepalive
1) "tcp-keepalive"
2) "300"
Default value 300 seconds (but can change on a Redis version).
If the client will not respond to the ACK-request from the server – this connection will be closed.
If both timeout and tcp-keepalive on the server-side will be set to the zero (i.e. disabled) – then “dead” connections will stay alive until server’s restart.
In our case backend developers are not sure that we are using the expire for all keys, and knowing the fact that Redis will be used for caching only – maxmemory-policy allkeys-lru can be set.
unixsocket
In case if Redis and an application are working together on the same host – you can try to use UNIX-sockets instead of the TCP-connections.
Redis can set the client’s connections queue to the value specified in the tcp-backlog (511 by default).
Still, the operating system has its own limit – net.core.somaxconn and if it is less then the Redis’ limit – then the warning will be produced:
The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128
What is the TCP backlog and net.core.somaxconn
To better understand where and how the tcp-backlog is applied and the net.core.somaxconn‘s role – let’s review how a TCP session is established:
a server: an application executes the listen() syscall passing to it a file descriptor to a socket, and in the second argument – the accept backlog size (the tcp-backlog value taken from the redis.conf)
a client: an application on the client-side executes connect() call and sends an SYN packet to the server
on the client side – the connection changes its state to the SYN_SENT
on the server’s side: a new connection is set to the SYN_RCVD state and will be saved in the syn backlog (net.ipv4.tcp_max_syn_backlog) – incomplete connection queue
the server: sends the SYN+ACK
the client: sends ACK, and changes the connection’s state to the ESTABLISHED state
the server: accepts ACK and set the connection state to the ESTABLISHED and moves it to the accept backlog – complete connection queue
the server: executes the accept() call passing a connection from the accept backlog
the client: executes the write() call and starts sending data
the server: calls the read() syscall and starts receiving data
So, if Redis will pass the tcp-backlog value to the listen() greater then the kernel has in its limit in thenet.core.somaxconn setting – you’ll get the “TCP backlog setting cannot be enforced” message.
The overcommit_memory steps in when Redis creates data snapshotting from the memory on the disk, specifically during the BGSAVE
In our current case, when Redis is used for caching only and has no RDB or AOF backups enabled – no need to change the overcommit_memory and best to leave it with its default value – 0.
In the case when you really want to set the boundaries by yourself – it’s best to use overcommit_memory == 2 and limit the overcommit by setting the overcommit_ratio or overcommit_kbytes parameters.
vm.swappiness
If an operating system has SWAP configured – it can dump some Redis’ data to the disk and later when Redis will try to access them – it can take a long time to read them back to the memory.