From 810e28a397b77fa16037354477370b564474d9be Mon Sep 17 00:00:00 2001 From: Jim Brunner Date: Tue, 15 Sep 2020 23:16:01 -0700 Subject: Incremental eviction processing (#7653) Rather than blindly evicting until maxmemory limit is achieved, this update adds a time limit to eviction. While over the maxmemory limit, eviction will process before each command AND as a timeProc when no commands are running. This will reduce the latency impact on many cases, especially pathological cases like massive used memory increase during dict rehashing. There is a risk that some other edge cases (like massive pipelined use of MGET) could cause Redis memory usage to keep growing despite the eviction attempts, so a new maxmemory-eviction-tenacity config is introduced to let users mitigate that. --- redis.conf | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'redis.conf') diff --git a/redis.conf b/redis.conf index 51f71484c..424dfa09a 100644 --- a/redis.conf +++ b/redis.conf @@ -912,6 +912,14 @@ acllog-max-len 128 # # maxmemory-samples 5 +# Eviction processing is designed to function well with the default setting. +# If there is an unusually large amount of write traffic, this value may need to +# be increased. Decreasing this value may reduce latency at the risk of +# eviction processing effectiveness +# 0 = minimum latency, 10 = default, 100 = process without regard to latency +# +# maxmemory-eviction-tenacity 10 + # Starting from Redis 5, by default a replica will ignore its maxmemory setting # (unless it is promoted to master after a failover or manually). It means # that the eviction of keys will be just handled by the master, sending the -- cgit v1.2.1