summaryrefslogtreecommitdiff
path: root/redis.conf
diff options
context:
space:
mode:
authorantirez <antirez@gmail.com>2010-04-15 18:07:57 +0200
committerantirez <antirez@gmail.com>2010-04-15 18:07:57 +0200
commit8ca3e9d10b013263a5356c81882b00e619a88720 (patch)
tree2cf467228ae55093e1d186b0264b122270098eb3 /redis.conf
parent5413c40da79d06b53b276b5358e04706a2738e9b (diff)
downloadredis-8ca3e9d10b013263a5356c81882b00e619a88720.tar.gz
Active rehashing
Diffstat (limited to 'redis.conf')
-rw-r--r--redis.conf20
1 files changed, 20 insertions, 0 deletions
diff --git a/redis.conf b/redis.conf
index 3b9a8e224..c9ff26cf9 100644
--- a/redis.conf
+++ b/redis.conf
@@ -262,6 +262,26 @@ glueoutputbuf yes
hash-max-zipmap-entries 64
hash-max-zipmap-value 512
+# Active rehashing uses 1 millisecond every 100 milliseconds of CPU time in
+# order to help rehashing the main Redis hash table (the one mapping top-level
+# keys to values). The hash table implementation redis uses (see dict.c)
+# performs a lazy rehashing: the more operation you run into an hash table
+# that is rhashing, the more rehashing "steps" are performed, so if the
+# server is idle the rehashing is never complete and some more memory is used
+# by the hash table.
+#
+# The default is to use this millisecond 10 times every second in order to
+# active rehashing the main dictionaries, freeing memory when possible.
+#
+# If unsure:
+# use "activerehashing no" if you have hard latency requirements and it is
+# not a good thing in your environment that Redis can reply form time to time
+# to queries with 2 milliseconds delay.
+#
+# use "activerehashing yes" if you don't have such hard requirements but
+# want to free memory asap when possible.
+activerehashing yes
+
################################## INCLUDES ###################################
# Include one or more other config files here. This is useful if you