142 lines
7.1 KiB
Text
Executable file
142 lines
7.1 KiB
Text
Executable file
# #ddev-generated
|
|
############################## MEMORY MANAGEMENT ################################
|
|
|
|
# Set a memory usage limit to the specified amount of bytes.
|
|
# When the memory limit is reached Redis will try to remove keys
|
|
# according to the eviction policy selected (see maxmemory-policy).
|
|
#
|
|
# If Redis can't remove keys according to the policy, or if the policy is
|
|
# set to 'noeviction', Redis will start to reply with errors to commands
|
|
# that would use more memory, like SET, LPUSH, and so on, and will continue
|
|
# to reply to read-only commands like GET.
|
|
#
|
|
# This option is usually useful when using Redis as an LRU or LFU cache, or to
|
|
# set a hard memory limit for an instance (using the 'noeviction' policy).
|
|
#
|
|
# WARNING: If you have replicas attached to an instance with maxmemory on,
|
|
# the size of the output buffers needed to feed the replicas are subtracted
|
|
# from the used memory count, so that network problems / resyncs will
|
|
# not trigger a loop where keys are evicted, and in turn the output
|
|
# buffer of replicas is full with DELs of keys evicted triggering the deletion
|
|
# of more keys, and so forth until the database is completely emptied.
|
|
#
|
|
# In short... if you have replicas attached it is suggested that you set a lower
|
|
# limit for maxmemory so that there is some free RAM on the system for replica
|
|
# output buffers (but this is not needed if the policy is 'noeviction').
|
|
#
|
|
maxmemory 512mb
|
|
|
|
# MAXMEMORY POLICY: how Redis will select what to remove when maxmemory
|
|
# is reached. You can select one from the following behaviors:
|
|
#
|
|
# volatile-lru -> Evict using approximated LRU, only keys with an expire set.
|
|
# allkeys-lru -> Evict any key using approximated LRU.
|
|
# volatile-lfu -> Evict using approximated LFU, only keys with an expire set.
|
|
# allkeys-lfu -> Evict any key using approximated LFU.
|
|
# volatile-random -> Remove a random key having an expire set.
|
|
# allkeys-random -> Remove a random key, any key.
|
|
# volatile-ttl -> Remove the key with the nearest expire time (minor TTL)
|
|
# noeviction -> Don't evict anything, just return an error on write operations.
|
|
#
|
|
# LRU means Least Recently Used
|
|
# LFU means Least Frequently Used
|
|
#
|
|
# Both LRU, LFU and volatile-ttl are implemented using approximated
|
|
# randomized algorithms.
|
|
#
|
|
# Note: with any of the above policies, Redis will return an error on write
|
|
# operations, when there are no suitable keys for eviction.
|
|
#
|
|
# At the date of writing these commands are: set setnx setex append
|
|
# incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd
|
|
# sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby
|
|
# zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby
|
|
# getset mset msetnx exec sort
|
|
#
|
|
# The default is:
|
|
#
|
|
maxmemory-policy allkeys-lru
|
|
|
|
# LRU, LFU and minimal TTL algorithms are not precise algorithms but approximated
|
|
# algorithms (in order to save memory), so you can tune it for speed or
|
|
# accuracy. By default Redis will check five keys and pick the one that was
|
|
# used least recently, you can change the sample size using the following
|
|
# configuration directive.
|
|
#
|
|
# The default of 5 produces good enough results. 10 Approximates very closely
|
|
# true LRU but costs more CPU. 3 is faster but not very accurate.
|
|
#
|
|
maxmemory-samples 4
|
|
|
|
# Redis reclaims expired keys in two ways: upon access when those keys are
|
|
# found to be expired, and also in background, in what is called the
|
|
# "active expire key". The key space is slowly and interactively scanned
|
|
# looking for expired keys to reclaim, so that it is possible to free memory
|
|
# of keys that are expired and will never be accessed again in a short time.
|
|
#
|
|
# The default effort of the expire cycle will try to avoid having more than
|
|
# ten percent of expired keys still in memory, and will try to avoid consuming
|
|
# more than 25% of total memory and to add latency to the system. However
|
|
# it is possible to increase the expire "effort" that is normally set to
|
|
# "1", to a greater value, up to the value "10". At its maximum value the
|
|
# system will use more CPU, longer cycles (and technically may introduce
|
|
# more latency), and will tolerate less already expired keys still present
|
|
# in the system. It's a tradeoff between memory, CPU and latency.
|
|
#
|
|
active-expire-effort 2
|
|
|
|
############################# LAZY FREEING ####################################
|
|
|
|
# Redis has two primitives to delete keys. One is called DEL and is a blocking
|
|
# deletion of the object. It means that the server stops processing new commands
|
|
# in order to reclaim all the memory associated with an object in a synchronous
|
|
# way. If the key deleted is associated with a small object, the time needed
|
|
# in order to execute the DEL command is very small and comparable to most other
|
|
# O(1) or O(log_N) commands in Redis. However if the key is associated with an
|
|
# aggregated value containing millions of elements, the server can block for
|
|
# a long time (even seconds) in order to complete the operation.
|
|
#
|
|
# For the above reasons Redis also offers non blocking deletion primitives
|
|
# such as UNLINK (non blocking DEL) and the ASYNC option of FLUSHALL and
|
|
# FLUSHDB commands, in order to reclaim memory in background. Those commands
|
|
# are executed in constant time. Another thread will incrementally free the
|
|
# object in the background as fast as possible.
|
|
#
|
|
# DEL, UNLINK and ASYNC option of FLUSHALL and FLUSHDB are user-controlled.
|
|
# It's up to the design of the application to understand when it is a good
|
|
# idea to use one or the other. However the Redis server sometimes has to
|
|
# delete keys or flush the whole database as a side effect of other operations.
|
|
# Specifically Redis deletes objects independently of a user call in the
|
|
# following scenarios:
|
|
#
|
|
# 1) On eviction, because of the maxmemory and maxmemory policy configurations,
|
|
# in order to make room for new data, without going over the specified
|
|
# memory limit.
|
|
# 2) Because of expire: when a key with an associated time to live (see the
|
|
# EXPIRE command) must be deleted from memory.
|
|
# 3) Because of a side effect of a command that stores data on a key that may
|
|
# already exist. For example the RENAME command may delete the old key
|
|
# content when it is replaced with another one. Similarly SUNIONSTORE
|
|
# or SORT with STORE option may delete existing keys. The SET command
|
|
# itself removes any old content of the specified key in order to replace
|
|
# it with the specified string.
|
|
# 4) During replication, when a replica performs a full resynchronization with
|
|
# its master, the content of the whole database is removed in order to
|
|
# load the RDB file just transferred.
|
|
#
|
|
# In all the above cases the default is to delete objects in a blocking way,
|
|
# like if DEL was called. However you can configure each case specifically
|
|
# in order to instead release memory in a non-blocking way like if UNLINK
|
|
# was called, using the following configuration directives.
|
|
|
|
lazyfree-lazy-eviction no
|
|
lazyfree-lazy-expire no
|
|
lazyfree-lazy-server-del no
|
|
replica-lazy-flush no
|
|
|
|
# It is also possible, for the case when to replace the user code DEL calls
|
|
# with UNLINK calls is not easy, to modify the default behavior of the DEL
|
|
# command to act exactly like UNLINK, using the following configuration
|
|
# directive:
|
|
|
|
lazyfree-lazy-user-del no
|