redis: redis.conf

"Fossies" - the Fresh Open Source Software Archive

Member "redis-7.0.8/redis.conf" (16 Jan 2023, 106545 Bytes) of package /linux/misc/redis-7.0.8.tar.gz:

As a special service "Fossies" has tried to format the requested source page into HTML format using (guessed) Generic config files source code syntax highlighting (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

1 # Redis configuration file example. 2 # 3 # Note that in order to read the configuration file, Redis must be 4 # started with the file path as first argument: 5 # 6 # ./redis-server /path/to/redis.conf 7 8 # Note on units: when memory size is needed, it is possible to specify 9 # it in the usual form of 1k 5GB 4M and so forth: 10 # 11 # 1k => 1000 bytes 12 # 1kb => 1024 bytes 13 # 1m => 1000000 bytes 14 # 1mb => 1024*1024 bytes 15 # 1g => 1000000000 bytes 16 # 1gb => 1024*1024*1024 bytes 17 # 18 # units are case insensitive so 1GB 1Gb 1gB are all the same. 19 20 ################################## INCLUDES ################################### 21 22 # Include one or more other config files here. This is useful if you 23 # have a standard template that goes to all Redis servers but also need 24 # to customize a few per-server settings. Include files can include 25 # other files, so use this wisely. 26 # 27 # Note that option "include" won't be rewritten by command "CONFIG REWRITE" 28 # from admin or Redis Sentinel. Since Redis always uses the last processed 29 # line as value of a configuration directive, you'd better put includes 30 # at the beginning of this file to avoid overwriting config change at runtime. 31 # 32 # If instead you are interested in using includes to override configuration 33 # options, it is better to use include as the last line. 34 # 35 # Included paths may contain wildcards. All files matching the wildcards will 36 # be included in alphabetical order. 37 # Note that if an include path contains a wildcards but no files match it when 38 # the server is started, the include statement will be ignored and no error will 39 # be emitted. It is safe, therefore, to include wildcard files from empty 40 # directories. 41 # 42 # include /path/to/local.conf 43 # include /path/to/other.conf 44 # include /path/to/fragments/*.conf 45 # 46 47 ################################## MODULES ##################################### 48 49 # Load modules at startup. If the server is not able to load modules 50 # it will abort. It is possible to use multiple loadmodule directives. 51 # 52 # loadmodule /path/to/my_module.so 53 # loadmodule /path/to/other_module.so 54 55 ################################## NETWORK ##################################### 56 57 # By default, if no "bind" configuration directive is specified, Redis listens 58 # for connections from all available network interfaces on the host machine. 59 # It is possible to listen to just one or multiple selected interfaces using 60 # the "bind" configuration directive, followed by one or more IP addresses. 61 # Each address can be prefixed by "-", which means that redis will not fail to 62 # start if the address is not available. Being not available only refers to 63 # addresses that does not correspond to any network interface. Addresses that 64 # are already in use will always fail, and unsupported protocols will always BE 65 # silently skipped. 66 # 67 # Examples: 68 # 69 # bind 192.168.1.100 10.0.0.1 # listens on two specific IPv4 addresses 70 # bind 127.0.0.1 ::1 # listens on loopback IPv4 and IPv6 71 # bind * -::* # like the default, all available interfaces 72 # 73 # ~~~ WARNING ~~~ If the computer running Redis is directly exposed to the 74 # internet, binding to all the interfaces is dangerous and will expose the 75 # instance to everybody on the internet. So by default we uncomment the 76 # following bind directive, that will force Redis to listen only on the 77 # IPv4 and IPv6 (if available) loopback interface addresses (this means Redis 78 # will only be able to accept client connections from the same host that it is 79 # running on). 80 # 81 # IF YOU ARE SURE YOU WANT YOUR INSTANCE TO LISTEN TO ALL THE INTERFACES 82 # COMMENT OUT THE FOLLOWING LINE. 83 # 84 # You will also need to set a password unless you explicitly disable protected 85 # mode. 86 # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 87 bind 127.0.0.1 -::1 88 89 # By default, outgoing connections (from replica to master, from Sentinel to 90 # instances, cluster bus, etc.) are not bound to a specific local address. In 91 # most cases, this means the operating system will handle that based on routing 92 # and the interface through which the connection goes out. 93 # 94 # Using bind-source-addr it is possible to configure a specific address to bind 95 # to, which may also affect how the connection gets routed. 96 # 97 # Example: 98 # 99 # bind-source-addr 10.0.0.1 100 101 # Protected mode is a layer of security protection, in order to avoid that 102 # Redis instances left open on the internet are accessed and exploited. 103 # 104 # When protected mode is on and the default user has no password, the server 105 # only accepts local connections from the IPv4 address (127.0.0.1), IPv6 address 106 # (::1) or Unix domain sockets. 107 # 108 # By default protected mode is enabled. You should disable it only if 109 # you are sure you want clients from other hosts to connect to Redis 110 # even if no authentication is configured. 111 protected-mode yes 112 113 # Redis uses default hardened security configuration directives to reduce the 114 # attack surface on innocent users. Therefore, several sensitive configuration 115 # directives are immutable, and some potentially-dangerous commands are blocked. 116 # 117 # Configuration directives that control files that Redis writes to (e.g., 'dir' 118 # and 'dbfilename') and that aren't usually modified during runtime 119 # are protected by making them immutable. 120 # 121 # Commands that can increase the attack surface of Redis and that aren't usually 122 # called by users are blocked by default. 123 # 124 # These can be exposed to either all connections or just local ones by setting 125 # each of the configs listed below to either of these values: 126 # 127 # no - Block for any connection (remain immutable) 128 # yes - Allow for any connection (no protection) 129 # local - Allow only for local connections. Ones originating from the 130 # IPv4 address (127.0.0.1), IPv6 address (::1) or Unix domain sockets. 131 # 132 # enable-protected-configs no 133 # enable-debug-command no 134 # enable-module-command no 135 136 # Accept connections on the specified port, default is 6379 (IANA #815344). 137 # If port 0 is specified Redis will not listen on a TCP socket. 138 port 6379 139 140 # TCP listen() backlog. 141 # 142 # In high requests-per-second environments you need a high backlog in order 143 # to avoid slow clients connection issues. Note that the Linux kernel 144 # will silently truncate it to the value of /proc/sys/net/core/somaxconn so 145 # make sure to raise both the value of somaxconn and tcp_max_syn_backlog 146 # in order to get the desired effect. 147 tcp-backlog 511 148 149 # Unix socket. 150 # 151 # Specify the path for the Unix socket that will be used to listen for 152 # incoming connections. There is no default, so Redis will not listen 153 # on a unix socket when not specified. 154 # 155 # unixsocket /run/redis.sock 156 # unixsocketperm 700 157 158 # Close the connection after a client is idle for N seconds (0 to disable) 159 timeout 0 160 161 # TCP keepalive. 162 # 163 # If non-zero, use SO_KEEPALIVE to send TCP ACKs to clients in absence 164 # of communication. This is useful for two reasons: 165 # 166 # 1) Detect dead peers. 167 # 2) Force network equipment in the middle to consider the connection to be 168 # alive. 169 # 170 # On Linux, the specified value (in seconds) is the period used to send ACKs. 171 # Note that to close the connection the double of the time is needed. 172 # On other kernels the period depends on the kernel configuration. 173 # 174 # A reasonable value for this option is 300 seconds, which is the new 175 # Redis default starting with Redis 3.2.1. 176 tcp-keepalive 300 177 178 # Apply OS-specific mechanism to mark the listening socket with the specified 179 # ID, to support advanced routing and filtering capabilities. 180 # 181 # On Linux, the ID represents a connection mark. 182 # On FreeBSD, the ID represents a socket cookie ID. 183 # On OpenBSD, the ID represents a route table ID. 184 # 185 # The default value is 0, which implies no marking is required. 186 # socket-mark-id 0 187 188 ################################# TLS/SSL ##################################### 189 190 # By default, TLS/SSL is disabled. To enable it, the "tls-port" configuration 191 # directive can be used to define TLS-listening ports. To enable TLS on the 192 # default port, use: 193 # 194 # port 0 195 # tls-port 6379 196 197 # Configure a X.509 certificate and private key to use for authenticating the 198 # server to connected clients, masters or cluster peers. These files should be 199 # PEM formatted. 200 # 201 # tls-cert-file redis.crt 202 # tls-key-file redis.key 203 # 204 # If the key file is encrypted using a passphrase, it can be included here 205 # as well. 206 # 207 # tls-key-file-pass secret 208 209 # Normally Redis uses the same certificate for both server functions (accepting 210 # connections) and client functions (replicating from a master, establishing 211 # cluster bus connections, etc.). 212 # 213 # Sometimes certificates are issued with attributes that designate them as 214 # client-only or server-only certificates. In that case it may be desired to use 215 # different certificates for incoming (server) and outgoing (client) 216 # connections. To do that, use the following directives: 217 # 218 # tls-client-cert-file client.crt 219 # tls-client-key-file client.key 220 # 221 # If the key file is encrypted using a passphrase, it can be included here 222 # as well. 223 # 224 # tls-client-key-file-pass secret 225 226 # Configure a DH parameters file to enable Diffie-Hellman (DH) key exchange, 227 # required by older versions of OpenSSL (<3.0). Newer versions do not require 228 # this configuration and recommend against it. 229 # 230 # tls-dh-params-file redis.dh 231 232 # Configure a CA certificate(s) bundle or directory to authenticate TLS/SSL 233 # clients and peers. Redis requires an explicit configuration of at least one 234 # of these, and will not implicitly use the system wide configuration. 235 # 236 # tls-ca-cert-file ca.crt 237 # tls-ca-cert-dir /etc/ssl/certs 238 239 # By default, clients (including replica servers) on a TLS port are required 240 # to authenticate using valid client side certificates. 241 # 242 # If "no" is specified, client certificates are not required and not accepted. 243 # If "optional" is specified, client certificates are accepted and must be 244 # valid if provided, but are not required. 245 # 246 # tls-auth-clients no 247 # tls-auth-clients optional 248 249 # By default, a Redis replica does not attempt to establish a TLS connection 250 # with its master. 251 # 252 # Use the following directive to enable TLS on replication links. 253 # 254 # tls-replication yes 255 256 # By default, the Redis Cluster bus uses a plain TCP connection. To enable 257 # TLS for the bus protocol, use the following directive: 258 # 259 # tls-cluster yes 260 261 # By default, only TLSv1.2 and TLSv1.3 are enabled and it is highly recommended 262 # that older formally deprecated versions are kept disabled to reduce the attack surface. 263 # You can explicitly specify TLS versions to support. 264 # Allowed values are case insensitive and include "TLSv1", "TLSv1.1", "TLSv1.2", 265 # "TLSv1.3" (OpenSSL >= 1.1.1) or any combination. 266 # To enable only TLSv1.2 and TLSv1.3, use: 267 # 268 # tls-protocols "TLSv1.2 TLSv1.3" 269 270 # Configure allowed ciphers. See the ciphers(1ssl) manpage for more information 271 # about the syntax of this string. 272 # 273 # Note: this configuration applies only to <= TLSv1.2. 274 # 275 # tls-ciphers DEFAULT:!MEDIUM 276 277 # Configure allowed TLSv1.3 ciphersuites. See the ciphers(1ssl) manpage for more 278 # information about the syntax of this string, and specifically for TLSv1.3 279 # ciphersuites. 280 # 281 # tls-ciphersuites TLS_CHACHA20_POLY1305_SHA256 282 283 # When choosing a cipher, use the server's preference instead of the client 284 # preference. By default, the server follows the client's preference. 285 # 286 # tls-prefer-server-ciphers yes 287 288 # By default, TLS session caching is enabled to allow faster and less expensive 289 # reconnections by clients that support it. Use the following directive to disable 290 # caching. 291 # 292 # tls-session-caching no 293 294 # Change the default number of TLS sessions cached. A zero value sets the cache 295 # to unlimited size. The default size is 20480. 296 # 297 # tls-session-cache-size 5000 298 299 # Change the default timeout of cached TLS sessions. The default timeout is 300 300 # seconds. 301 # 302 # tls-session-cache-timeout 60 303 304 ################################# GENERAL ##################################### 305 306 # By default Redis does not run as a daemon. Use 'yes' if you need it. 307 # Note that Redis will write a pid file in /var/run/redis.pid when daemonized. 308 # When Redis is supervised by upstart or systemd, this parameter has no impact. 309 daemonize no 310 311 # If you run Redis from upstart or systemd, Redis can interact with your 312 # supervision tree. Options: 313 # supervised no - no supervision interaction 314 # supervised upstart - signal upstart by putting Redis into SIGSTOP mode 315 # requires "expect stop" in your upstart job config 316 # supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET 317 # on startup, and updating Redis status on a regular 318 # basis. 319 # supervised auto - detect upstart or systemd method based on 320 # UPSTART_JOB or NOTIFY_SOCKET environment variables 321 # Note: these supervision methods only signal "process is ready." 322 # They do not enable continuous pings back to your supervisor. 323 # 324 # The default is "no". To run under upstart/systemd, you can simply uncomment 325 # the line below: 326 # 327 # supervised auto 328 329 # If a pid file is specified, Redis writes it where specified at startup 330 # and removes it at exit. 331 # 332 # When the server runs non daemonized, no pid file is created if none is 333 # specified in the configuration. When the server is daemonized, the pid file 334 # is used even if not specified, defaulting to "/var/run/redis.pid". 335 # 336 # Creating a pid file is best effort: if Redis is not able to create it 337 # nothing bad happens, the server will start and run normally. 338 # 339 # Note that on modern Linux systems "/run/redis.pid" is more conforming 340 # and should be used instead. 341 pidfile /var/run/redis_6379.pid 342 343 # Specify the server verbosity level. 344 # This can be one of: 345 # debug (a lot of information, useful for development/testing) 346 # verbose (many rarely useful info, but not a mess like the debug level) 347 # notice (moderately verbose, what you want in production probably) 348 # warning (only very important / critical messages are logged) 349 loglevel notice 350 351 # Specify the log file name. Also the empty string can be used to force 352 # Redis to log on the standard output. Note that if you use standard 353 # output for logging but daemonize, logs will be sent to /dev/null 354 logfile "" 355 356 # To enable logging to the system logger, just set 'syslog-enabled' to yes, 357 # and optionally update the other syslog parameters to suit your needs. 358 # syslog-enabled no 359 360 # Specify the syslog identity. 361 # syslog-ident redis 362 363 # Specify the syslog facility. Must be USER or between LOCAL0-LOCAL7. 364 # syslog-facility local0 365 366 # To disable the built in crash log, which will possibly produce cleaner core 367 # dumps when they are needed, uncomment the following: 368 # 369 # crash-log-enabled no 370 371 # To disable the fast memory check that's run as part of the crash log, which 372 # will possibly let redis terminate sooner, uncomment the following: 373 # 374 # crash-memcheck-enabled no 375 376 # Set the number of databases. The default database is DB 0, you can select 377 # a different one on a per-connection basis using SELECT <dbid> where 378 # dbid is a number between 0 and 'databases'-1 379 databases 16 380 381 # By default Redis shows an ASCII art logo only when started to log to the 382 # standard output and if the standard output is a TTY and syslog logging is 383 # disabled. Basically this means that normally a logo is displayed only in 384 # interactive sessions. 385 # 386 # However it is possible to force the pre-4.0 behavior and always show a 387 # ASCII art logo in startup logs by setting the following option to yes. 388 always-show-logo no 389 390 # By default, Redis modifies the process title (as seen in 'top' and 'ps') to 391 # provide some runtime information. It is possible to disable this and leave 392 # the process name as executed by setting the following to no. 393 set-proc-title yes 394 395 # When changing the process title, Redis uses the following template to construct 396 # the modified title. 397 # 398 # Template variables are specified in curly brackets. The following variables are 399 # supported: 400 # 401 # {title} Name of process as executed if parent, or type of child process. 402 # {listen-addr} Bind address or '*' followed by TCP or TLS port listening on, or 403 # Unix socket if only that's available. 404 # {server-mode} Special mode, i.e. "[sentinel]" or "[cluster]". 405 # {port} TCP port listening on, or 0. 406 # {tls-port} TLS port listening on, or 0. 407 # {unixsocket} Unix domain socket listening on, or "". 408 # {config-file} Name of configuration file used. 409 # 410 proc-title-template "{title} {listen-addr} {server-mode}" 411 412 ################################ SNAPSHOTTING ################################ 413 414 # Save the DB to disk. 415 # 416 # save <seconds> <changes> [<seconds> <changes> ...] 417 # 418 # Redis will save the DB if the given number of seconds elapsed and it 419 # surpassed the given number of write operations against the DB. 420 # 421 # Snapshotting can be completely disabled with a single empty string argument 422 # as in following example: 423 # 424 # save "" 425 # 426 # Unless specified otherwise, by default Redis will save the DB: 427 # * After 3600 seconds (an hour) if at least 1 change was performed 428 # * After 300 seconds (5 minutes) if at least 100 changes were performed 429 # * After 60 seconds if at least 10000 changes were performed 430 # 431 # You can set these explicitly by uncommenting the following line. 432 # 433 # save 3600 1 300 100 60 10000 434 435 # By default Redis will stop accepting writes if RDB snapshots are enabled 436 # (at least one save point) and the latest background save failed. 437 # This will make the user aware (in a hard way) that data is not persisting 438 # on disk properly, otherwise chances are that no one will notice and some 439 # disaster will happen. 440 # 441 # If the background saving process will start working again Redis will 442 # automatically allow writes again. 443 # 444 # However if you have setup your proper monitoring of the Redis server 445 # and persistence, you may want to disable this feature so that Redis will 446 # continue to work as usual even if there are problems with disk, 447 # permissions, and so forth. 448 stop-writes-on-bgsave-error yes 449 450 # Compress string objects using LZF when dump .rdb databases? 451 # By default compression is enabled as it's almost always a win. 452 # If you want to save some CPU in the saving child set it to 'no' but 453 # the dataset will likely be bigger if you have compressible values or keys. 454 rdbcompression yes 455 456 # Since version 5 of RDB a CRC64 checksum is placed at the end of the file. 457 # This makes the format more resistant to corruption but there is a performance 458 # hit to pay (around 10%) when saving and loading RDB files, so you can disable it 459 # for maximum performances. 460 # 461 # RDB files created with checksum disabled have a checksum of zero that will 462 # tell the loading code to skip the check. 463 rdbchecksum yes 464 465 # Enables or disables full sanitization checks for ziplist and listpack etc when 466 # loading an RDB or RESTORE payload. This reduces the chances of a assertion or 467 # crash later on while processing commands. 468 # Options: 469 # no - Never perform full sanitization 470 # yes - Always perform full sanitization 471 # clients - Perform full sanitization only for user connections. 472 # Excludes: RDB files, RESTORE commands received from the master 473 # connection, and client connections which have the 474 # skip-sanitize-payload ACL flag. 475 # The default should be 'clients' but since it currently affects cluster 476 # resharding via MIGRATE, it is temporarily set to 'no' by default. 477 # 478 # sanitize-dump-payload no 479 480 # The filename where to dump the DB 481 dbfilename dump.rdb 482 483 # Remove RDB files used by replication in instances without persistence 484 # enabled. By default this option is disabled, however there are environments 485 # where for regulations or other security concerns, RDB files persisted on 486 # disk by masters in order to feed replicas, or stored on disk by replicas 487 # in order to load them for the initial synchronization, should be deleted 488 # ASAP. Note that this option ONLY WORKS in instances that have both AOF 489 # and RDB persistence disabled, otherwise is completely ignored. 490 # 491 # An alternative (and sometimes better) way to obtain the same effect is 492 # to use diskless replication on both master and replicas instances. However 493 # in the case of replicas, diskless is not always an option. 494 rdb-del-sync-files no 495 496 # The working directory. 497 # 498 # The DB will be written inside this directory, with the filename specified 499 # above using the 'dbfilename' configuration directive. 500 # 501 # The Append Only File will also be created inside this directory. 502 # 503 # Note that you must specify a directory here, not a file name. 504 dir ./ 505 506 ################################# REPLICATION ################################# 507 508 # Master-Replica replication. Use replicaof to make a Redis instance a copy of 509 # another Redis server. A few things to understand ASAP about Redis replication. 510 # 511 # +------------------+ +---------------+ 512 # | Master | ---> | Replica | 513 # | (receive writes) | | (exact copy) | 514 # +------------------+ +---------------+ 515 # 516 # 1) Redis replication is asynchronous, but you can configure a master to 517 # stop accepting writes if it appears to be not connected with at least 518 # a given number of replicas. 519 # 2) Redis replicas are able to perform a partial resynchronization with the 520 # master if the replication link is lost for a relatively small amount of 521 # time. You may want to configure the replication backlog size (see the next 522 # sections of this file) with a sensible value depending on your needs. 523 # 3) Replication is automatic and does not need user intervention. After a 524 # network partition replicas automatically try to reconnect to masters 525 # and resynchronize with them. 526 # 527 # replicaof <masterip> <masterport> 528 529 # If the master is password protected (using the "requirepass" configuration 530 # directive below) it is possible to tell the replica to authenticate before 531 # starting the replication synchronization process, otherwise the master will 532 # refuse the replica request. 533 # 534 # masterauth <master-password> 535 # 536 # However this is not enough if you are using Redis ACLs (for Redis version 537 # 6 or greater), and the default user is not capable of running the PSYNC 538 # command and/or other commands needed for replication. In this case it's 539 # better to configure a special user to use with replication, and specify the 540 # masteruser configuration as such: 541 # 542 # masteruser <username> 543 # 544 # When masteruser is specified, the replica will authenticate against its 545 # master using the new AUTH form: AUTH <username> <password>. 546 547 # When a replica loses its connection with the master, or when the replication 548 # is still in progress, the replica can act in two different ways: 549 # 550 # 1) if replica-serve-stale-data is set to 'yes' (the default) the replica will 551 # still reply to client requests, possibly with out of date data, or the 552 # data set may just be empty if this is the first synchronization. 553 # 554 # 2) If replica-serve-stale-data is set to 'no' the replica will reply with error 555 # "MASTERDOWN Link with MASTER is down and replica-serve-stale-data is set to 'no'" 556 # to all data access commands, excluding commands such as: 557 # INFO, REPLICAOF, AUTH, SHUTDOWN, REPLCONF, ROLE, CONFIG, SUBSCRIBE, 558 # UNSUBSCRIBE, PSUBSCRIBE, PUNSUBSCRIBE, PUBLISH, PUBSUB, COMMAND, POST, 559 # HOST and LATENCY. 560 # 561 replica-serve-stale-data yes 562 563 # You can configure a replica instance to accept writes or not. Writing against 564 # a replica instance may be useful to store some ephemeral data (because data 565 # written on a replica will be easily deleted after resync with the master) but 566 # may also cause problems if clients are writing to it because of a 567 # misconfiguration. 568 # 569 # Since Redis 2.6 by default replicas are read-only. 570 # 571 # Note: read only replicas are not designed to be exposed to untrusted clients 572 # on the internet. It's just a protection layer against misuse of the instance. 573 # Still a read only replica exports by default all the administrative commands 574 # such as CONFIG, DEBUG, and so forth. To a limited extent you can improve 575 # security of read only replicas using 'rename-command' to shadow all the 576 # administrative / dangerous commands. 577 replica-read-only yes 578 579 # Replication SYNC strategy: disk or socket. 580 # 581 # New replicas and reconnecting replicas that are not able to continue the 582 # replication process just receiving differences, need to do what is called a 583 # "full synchronization". An RDB file is transmitted from the master to the 584 # replicas. 585 # 586 # The transmission can happen in two different ways: 587 # 588 # 1) Disk-backed: The Redis master creates a new process that writes the RDB 589 # file on disk. Later the file is transferred by the parent 590 # process to the replicas incrementally. 591 # 2) Diskless: The Redis master creates a new process that directly writes the 592 # RDB file to replica sockets, without touching the disk at all. 593 # 594 # With disk-backed replication, while the RDB file is generated, more replicas 595 # can be queued and served with the RDB file as soon as the current child 596 # producing the RDB file finishes its work. With diskless replication instead 597 # once the transfer starts, new replicas arriving will be queued and a new 598 # transfer will start when the current one terminates. 599 # 600 # When diskless replication is used, the master waits a configurable amount of 601 # time (in seconds) before starting the transfer in the hope that multiple 602 # replicas will arrive and the transfer can be parallelized. 603 # 604 # With slow disks and fast (large bandwidth) networks, diskless replication 605 # works better. 606 repl-diskless-sync yes 607 608 # When diskless replication is enabled, it is possible to configure the delay 609 # the server waits in order to spawn the child that transfers the RDB via socket 610 # to the replicas. 611 # 612 # This is important since once the transfer starts, it is not possible to serve 613 # new replicas arriving, that will be queued for the next RDB transfer, so the 614 # server waits a delay in order to let more replicas arrive. 615 # 616 # The delay is specified in seconds, and by default is 5 seconds. To disable 617 # it entirely just set it to 0 seconds and the transfer will start ASAP. 618 repl-diskless-sync-delay 5 619 620 # When diskless replication is enabled with a delay, it is possible to let 621 # the replication start before the maximum delay is reached if the maximum 622 # number of replicas expected have connected. Default of 0 means that the 623 # maximum is not defined and Redis will wait the full delay. 624 repl-diskless-sync-max-replicas 0 625 626 # ----------------------------------------------------------------------------- 627 # WARNING: RDB diskless load is experimental. Since in this setup the replica 628 # does not immediately store an RDB on disk, it may cause data loss during 629 # failovers. RDB diskless load + Redis modules not handling I/O reads may also 630 # cause Redis to abort in case of I/O errors during the initial synchronization 631 # stage with the master. Use only if you know what you are doing. 632 # ----------------------------------------------------------------------------- 633 # 634 # Replica can load the RDB it reads from the replication link directly from the 635 # socket, or store the RDB to a file and read that file after it was completely 636 # received from the master. 637 # 638 # In many cases the disk is slower than the network, and storing and loading 639 # the RDB file may increase replication time (and even increase the master's 640 # Copy on Write memory and replica buffers). 641 # However, parsing the RDB file directly from the socket may mean that we have 642 # to flush the contents of the current database before the full rdb was 643 # received. For this reason we have the following options: 644 # 645 # "disabled" - Don't use diskless load (store the rdb file to the disk first) 646 # "on-empty-db" - Use diskless load only when it is completely safe. 647 # "swapdb" - Keep current db contents in RAM while parsing the data directly 648 # from the socket. Replicas in this mode can keep serving current 649 # data set while replication is in progress, except for cases where 650 # they can't recognize master as having a data set from same 651 # replication history. 652 # Note that this requires sufficient memory, if you don't have it, 653 # you risk an OOM kill. 654 repl-diskless-load disabled 655 656 # Master send PINGs to its replicas in a predefined interval. It's possible to 657 # change this interval with the repl_ping_replica_period option. The default 658 # value is 10 seconds. 659 # 660 # repl-ping-replica-period 10 661 662 # The following option sets the replication timeout for: 663 # 664 # 1) Bulk transfer I/O during SYNC, from the point of view of replica. 665 # 2) Master timeout from the point of view of replicas (data, pings). 666 # 3) Replica timeout from the point of view of masters (REPLCONF ACK pings). 667 # 668 # It is important to make sure that this value is greater than the value 669 # specified for repl-ping-replica-period otherwise a timeout will be detected 670 # every time there is low traffic between the master and the replica. The default 671 # value is 60 seconds. 672 # 673 # repl-timeout 60 674 675 # Disable TCP_NODELAY on the replica socket after SYNC? 676 # 677 # If you select "yes" Redis will use a smaller number of TCP packets and 678 # less bandwidth to send data to replicas. But this can add a delay for 679 # the data to appear on the replica side, up to 40 milliseconds with 680 # Linux kernels using a default configuration. 681 # 682 # If you select "no" the delay for data to appear on the replica side will 683 # be reduced but more bandwidth will be used for replication. 684 # 685 # By default we optimize for low latency, but in very high traffic conditions 686 # or when the master and replicas are many hops away, turning this to "yes" may 687 # be a good idea. 688 repl-disable-tcp-nodelay no 689 690 # Set the replication backlog size. The backlog is a buffer that accumulates 691 # replica data when replicas are disconnected for some time, so that when a 692 # replica wants to reconnect again, often a full resync is not needed, but a 693 # partial resync is enough, just passing the portion of data the replica 694 # missed while disconnected. 695 # 696 # The bigger the replication backlog, the longer the replica can endure the 697 # disconnect and later be able to perform a partial resynchronization. 698 # 699 # The backlog is only allocated if there is at least one replica connected. 700 # 701 # repl-backlog-size 1mb 702 703 # After a master has no connected replicas for some time, the backlog will be 704 # freed. The following option configures the amount of seconds that need to 705 # elapse, starting from the time the last replica disconnected, for the backlog 706 # buffer to be freed. 707 # 708 # Note that replicas never free the backlog for timeout, since they may be 709 # promoted to masters later, and should be able to correctly "partially 710 # resynchronize" with other replicas: hence they should always accumulate backlog. 711 # 712 # A value of 0 means to never release the backlog. 713 # 714 # repl-backlog-ttl 3600 715 716 # The replica priority is an integer number published by Redis in the INFO 717 # output. It is used by Redis Sentinel in order to select a replica to promote 718 # into a master if the master is no longer working correctly. 719 # 720 # A replica with a low priority number is considered better for promotion, so 721 # for instance if there are three replicas with priority 10, 100, 25 Sentinel 722 # will pick the one with priority 10, that is the lowest. 723 # 724 # However a special priority of 0 marks the replica as not able to perform the 725 # role of master, so a replica with priority of 0 will never be selected by 726 # Redis Sentinel for promotion. 727 # 728 # By default the priority is 100. 729 replica-priority 100 730 731 # The propagation error behavior controls how Redis will behave when it is 732 # unable to handle a command being processed in the replication stream from a master 733 # or processed while reading from an AOF file. Errors that occur during propagation 734 # are unexpected, and can cause data inconsistency. However, there are edge cases 735 # in earlier versions of Redis where it was possible for the server to replicate or persist 736 # commands that would fail on future versions. For this reason the default behavior 737 # is to ignore such errors and continue processing commands. 738 # 739 # If an application wants to ensure there is no data divergence, this configuration 740 # should be set to 'panic' instead. The value can also be set to 'panic-on-replicas' 741 # to only panic when a replica encounters an error on the replication stream. One of 742 # these two panic values will become the default value in the future once there are 743 # sufficient safety mechanisms in place to prevent false positive crashes. 744 # 745 # propagation-error-behavior ignore 746 747 # Replica ignore disk write errors controls the behavior of a replica when it is 748 # unable to persist a write command received from its master to disk. By default, 749 # this configuration is set to 'no' and will crash the replica in this condition. 750 # It is not recommended to change this default, however in order to be compatible 751 # with older versions of Redis this config can be toggled to 'yes' which will just 752 # log a warning and execute the write command it got from the master. 753 # 754 # replica-ignore-disk-write-errors no 755 756 # ----------------------------------------------------------------------------- 757 # By default, Redis Sentinel includes all replicas in its reports. A replica 758 # can be excluded from Redis Sentinel's announcements. An unannounced replica 759 # will be ignored by the 'sentinel replicas <master>' command and won't be 760 # exposed to Redis Sentinel's clients. 761 # 762 # This option does not change the behavior of replica-priority. Even with 763 # replica-announced set to 'no', the replica can be promoted to master. To 764 # prevent this behavior, set replica-priority to 0. 765 # 766 # replica-announced yes 767 768 # It is possible for a master to stop accepting writes if there are less than 769 # N replicas connected, having a lag less or equal than M seconds. 770 # 771 # The N replicas need to be in "online" state. 772 # 773 # The lag in seconds, that must be <= the specified value, is calculated from 774 # the last ping received from the replica, that is usually sent every second. 775 # 776 # This option does not GUARANTEE that N replicas will accept the write, but 777 # will limit the window of exposure for lost writes in case not enough replicas 778 # are available, to the specified number of seconds. 779 # 780 # For example to require at least 3 replicas with a lag <= 10 seconds use: 781 # 782 # min-replicas-to-write 3 783 # min-replicas-max-lag 10 784 # 785 # Setting one or the other to 0 disables the feature. 786 # 787 # By default min-replicas-to-write is set to 0 (feature disabled) and 788 # min-replicas-max-lag is set to 10. 789 790 # A Redis master is able to list the address and port of the attached 791 # replicas in different ways. For example the "INFO replication" section 792 # offers this information, which is used, among other tools, by 793 # Redis Sentinel in order to discover replica instances. 794 # Another place where this info is available is in the output of the 795 # "ROLE" command of a master. 796 # 797 # The listed IP address and port normally reported by a replica is 798 # obtained in the following way: 799 # 800 # IP: The address is auto detected by checking the peer address 801 # of the socket used by the replica to connect with the master. 802 # 803 # Port: The port is communicated by the replica during the replication 804 # handshake, and is normally the port that the replica is using to 805 # listen for connections. 806 # 807 # However when port forwarding or Network Address Translation (NAT) is 808 # used, the replica may actually be reachable via different IP and port 809 # pairs. The following two options can be used by a replica in order to 810 # report to its master a specific set of IP and port, so that both INFO 811 # and ROLE will report those values. 812 # 813 # There is no need to use both the options if you need to override just 814 # the port or the IP address. 815 # 816 # replica-announce-ip 5.5.5.5 817 # replica-announce-port 1234 818 819 ############################### KEYS TRACKING ################################# 820 821 # Redis implements server assisted support for client side caching of values. 822 # This is implemented using an invalidation table that remembers, using 823 # a radix key indexed by key name, what clients have which keys. In turn 824 # this is used in order to send invalidation messages to clients. Please 825 # check this page to understand more about the feature: 826 # 827 # https://redis.io/topics/client-side-caching 828 # 829 # When tracking is enabled for a client, all the read only queries are assumed 830 # to be cached: this will force Redis to store information in the invalidation 831 # table. When keys are modified, such information is flushed away, and 832 # invalidation messages are sent to the clients. However if the workload is 833 # heavily dominated by reads, Redis could use more and more memory in order 834 # to track the keys fetched by many clients. 835 # 836 # For this reason it is possible to configure a maximum fill value for the 837 # invalidation table. By default it is set to 1M of keys, and once this limit 838 # is reached, Redis will start to evict keys in the invalidation table 839 # even if they were not modified, just to reclaim memory: this will in turn 840 # force the clients to invalidate the cached values. Basically the table 841 # maximum size is a trade off between the memory you want to spend server 842 # side to track information about who cached what, and the ability of clients 843 # to retain cached objects in memory. 844 # 845 # If you set the value to 0, it means there are no limits, and Redis will 846 # retain as many keys as needed in the invalidation table. 847 # In the "stats" INFO section, you can find information about the number of 848 # keys in the invalidation table at every given moment. 849 # 850 # Note: when key tracking is used in broadcasting mode, no memory is used 851 # in the server side so this setting is useless. 852 # 853 # tracking-table-max-keys 1000000 854 855 ################################## SECURITY ################################### 856 857 # Warning: since Redis is pretty fast, an outside user can try up to 858 # 1 million passwords per second against a modern box. This means that you 859 # should use very strong passwords, otherwise they will be very easy to break. 860 # Note that because the password is really a shared secret between the client 861 # and the server, and should not be memorized by any human, the password 862 # can be easily a long string from /dev/urandom or whatever, so by using a 863 # long and unguessable password no brute force attack will be possible. 864 865 # Redis ACL users are defined in the following format: 866 # 867 # user <username> ... acl rules ... 868 # 869 # For example: 870 # 871 # user worker +@list +@connection ~jobs:* on >ffa9203c493aa99 872 # 873 # The special username "default" is used for new connections. If this user 874 # has the "nopass" rule, then new connections will be immediately authenticated 875 # as the "default" user without the need of any password provided via the 876 # AUTH command. Otherwise if the "default" user is not flagged with "nopass" 877 # the connections will start in not authenticated state, and will require 878 # AUTH (or the HELLO command AUTH option) in order to be authenticated and 879 # start to work. 880 # 881 # The ACL rules that describe what a user can do are the following: 882 # 883 # on Enable the user: it is possible to authenticate as this user. 884 # off Disable the user: it's no longer possible to authenticate 885 # with this user, however the already authenticated connections 886 # will still work. 887 # skip-sanitize-payload RESTORE dump-payload sanitization is skipped. 888 # sanitize-payload RESTORE dump-payload is sanitized (default). 889 # +<command> Allow the execution of that command. 890 # May be used with `|` for allowing subcommands (e.g "+config|get") 891 # -<command> Disallow the execution of that command. 892 # May be used with `|` for blocking subcommands (e.g "-config|set") 893 # +@<category> Allow the execution of all the commands in such category 894 # with valid categories are like @admin, @set, @sortedset, ... 895 # and so forth, see the full list in the server.c file where 896 # the Redis command table is described and defined. 897 # The special category @all means all the commands, but currently 898 # present in the server, and that will be loaded in the future 899 # via modules. 900 # +<command>|first-arg Allow a specific first argument of an otherwise 901 # disabled command. It is only supported on commands with 902 # no sub-commands, and is not allowed as negative form 903 # like -SELECT|1, only additive starting with "+". This 904 # feature is deprecated and may be removed in the future. 905 # allcommands Alias for +@all. Note that it implies the ability to execute 906 # all the future commands loaded via the modules system. 907 # nocommands Alias for -@all. 908 # ~<pattern> Add a pattern of keys that can be mentioned as part of 909 # commands. For instance ~* allows all the keys. The pattern 910 # is a glob-style pattern like the one of KEYS. 911 # It is possible to specify multiple patterns. 912 # %R~<pattern> Add key read pattern that specifies which keys can be read 913 # from. 914 # %W~<pattern> Add key write pattern that specifies which keys can be 915 # written to. 916 # allkeys Alias for ~* 917 # resetkeys Flush the list of allowed keys patterns. 918 # &<pattern> Add a glob-style pattern of Pub/Sub channels that can be 919 # accessed by the user. It is possible to specify multiple channel 920 # patterns. 921 # allchannels Alias for &* 922 # resetchannels Flush the list of allowed channel patterns. 923 # ><password> Add this password to the list of valid password for the user. 924 # For example >mypass will add "mypass" to the list. 925 # This directive clears the "nopass" flag (see later). 926 # <<password> Remove this password from the list of valid passwords. 927 # nopass All the set passwords of the user are removed, and the user 928 # is flagged as requiring no password: it means that every 929 # password will work against this user. If this directive is 930 # used for the default user, every new connection will be 931 # immediately authenticated with the default user without 932 # any explicit AUTH command required. Note that the "resetpass" 933 # directive will clear this condition. 934 # resetpass Flush the list of allowed passwords. Moreover removes the 935 # "nopass" status. After "resetpass" the user has no associated 936 # passwords and there is no way to authenticate without adding 937 # some password (or setting it as "nopass" later). 938 # reset Performs the following actions: resetpass, resetkeys, off, 939 # -@all. The user returns to the same state it has immediately 940 # after its creation. 941 # (<options>) Create a new selector with the options specified within the 942 # parentheses and attach it to the user. Each option should be 943 # space separated. The first character must be ( and the last 944 # character must be ). 945 # clearselectors Remove all of the currently attached selectors. 946 # Note this does not change the "root" user permissions, 947 # which are the permissions directly applied onto the 948 # user (outside the parentheses). 949 # 950 # ACL rules can be specified in any order: for instance you can start with 951 # passwords, then flags, or key patterns. However note that the additive 952 # and subtractive rules will CHANGE MEANING depending on the ordering. 953 # For instance see the following example: 954 # 955 # user alice on +@all -DEBUG ~* >somepassword 956 # 957 # This will allow "alice" to use all the commands with the exception of the 958 # DEBUG command, since +@all added all the commands to the set of the commands 959 # alice can use, and later DEBUG was removed. However if we invert the order 960 # of two ACL rules the result will be different: 961 # 962 # user alice on -DEBUG +@all ~* >somepassword 963 # 964 # Now DEBUG was removed when alice had yet no commands in the set of allowed 965 # commands, later all the commands are added, so the user will be able to 966 # execute everything. 967 # 968 # Basically ACL rules are processed left-to-right. 969 # 970 # The following is a list of command categories and their meanings: 971 # * keyspace - Writing or reading from keys, databases, or their metadata 972 # in a type agnostic way. Includes DEL, RESTORE, DUMP, RENAME, EXISTS, DBSIZE, 973 # KEYS, EXPIRE, TTL, FLUSHALL, etc. Commands that may modify the keyspace, 974 # key or metadata will also have `write` category. Commands that only read 975 # the keyspace, key or metadata will have the `read` category. 976 # * read - Reading from keys (values or metadata). Note that commands that don't 977 # interact with keys, will not have either `read` or `write`. 978 # * write - Writing to keys (values or metadata) 979 # * admin - Administrative commands. Normal applications will never need to use 980 # these. Includes REPLICAOF, CONFIG, DEBUG, SAVE, MONITOR, ACL, SHUTDOWN, etc. 981 # * dangerous - Potentially dangerous (each should be considered with care for 982 # various reasons). This includes FLUSHALL, MIGRATE, RESTORE, SORT, KEYS, 983 # CLIENT, DEBUG, INFO, CONFIG, SAVE, REPLICAOF, etc. 984 # * connection - Commands affecting the connection or other connections. 985 # This includes AUTH, SELECT, COMMAND, CLIENT, ECHO, PING, etc. 986 # * blocking - Potentially blocking the connection until released by another 987 # command. 988 # * fast - Fast O(1) commands. May loop on the number of arguments, but not the 989 # number of elements in the key. 990 # * slow - All commands that are not Fast. 991 # * pubsub - PUBLISH / SUBSCRIBE related 992 # * transaction - WATCH / MULTI / EXEC related commands. 993 # * scripting - Scripting related. 994 # * set - Data type: sets related. 995 # * sortedset - Data type: zsets related. 996 # * list - Data type: lists related. 997 # * hash - Data type: hashes related. 998 # * string - Data type: strings related. 999 # * bitmap - Data type: bitmaps related. 1000 # * hyperloglog - Data type: hyperloglog related. 1001 # * geo - Data type: geo related. 1002 # * stream - Data type: streams related. 1003 # 1004 # For more information about ACL configuration please refer to 1005 # the Redis web site at https://redis.io/topics/acl 1006 1007 # ACL LOG 1008 # 1009 # The ACL Log tracks failed commands and authentication events associated 1010 # with ACLs. The ACL Log is useful to troubleshoot failed commands blocked 1011 # by ACLs. The ACL Log is stored in memory. You can reclaim memory with 1012 # ACL LOG RESET. Define the maximum entry length of the ACL Log below. 1013 acllog-max-len 128 1014 1015 # Using an external ACL file 1016 # 1017 # Instead of configuring users here in this file, it is possible to use 1018 # a stand-alone file just listing users. The two methods cannot be mixed: 1019 # if you configure users here and at the same time you activate the external 1020 # ACL file, the server will refuse to start. 1021 # 1022 # The format of the external ACL user file is exactly the same as the 1023 # format that is used inside redis.conf to describe users. 1024 # 1025 # aclfile /etc/redis/users.acl 1026 1027 # IMPORTANT NOTE: starting with Redis 6 "requirepass" is just a compatibility 1028 # layer on top of the new ACL system. The option effect will be just setting 1029 # the password for the default user. Clients will still authenticate using 1030 # AUTH <password> as usually, or more explicitly with AUTH default <password> 1031 # if they follow the new protocol: both will work. 1032 # 1033 # The requirepass is not compatible with aclfile option and the ACL LOAD 1034 # command, these will cause requirepass to be ignored. 1035 # 1036 # requirepass foobared 1037 1038 # New users are initialized with restrictive permissions by default, via the 1039 # equivalent of this ACL rule 'off resetkeys -@all'. Starting with Redis 6.2, it 1040 # is possible to manage access to Pub/Sub channels with ACL rules as well. The 1041 # default Pub/Sub channels permission if new users is controlled by the 1042 # acl-pubsub-default configuration directive, which accepts one of these values: 1043 # 1044 # allchannels: grants access to all Pub/Sub channels 1045 # resetchannels: revokes access to all Pub/Sub channels 1046 # 1047 # From Redis 7.0, acl-pubsub-default defaults to 'resetchannels' permission. 1048 # 1049 # acl-pubsub-default resetchannels 1050 1051 # Command renaming (DEPRECATED). 1052 # 1053 # ------------------------------------------------------------------------ 1054 # WARNING: avoid using this option if possible. Instead use ACLs to remove 1055 # commands from the default user, and put them only in some admin user you 1056 # create for administrative purposes. 1057 # ------------------------------------------------------------------------ 1058 # 1059 # It is possible to change the name of dangerous commands in a shared 1060 # environment. For instance the CONFIG command may be renamed into something 1061 # hard to guess so that it will still be available for internal-use tools 1062 # but not available for general clients. 1063 # 1064 # Example: 1065 # 1066 # rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52 1067 # 1068 # It is also possible to completely kill a command by renaming it into 1069 # an empty string: 1070 # 1071 # rename-command CONFIG "" 1072 # 1073 # Please note that changing the name of commands that are logged into the 1074 # AOF file or transmitted to replicas may cause problems. 1075 1076 ################################### CLIENTS #################################### 1077 1078 # Set the max number of connected clients at the same time. By default 1079 # this limit is set to 10000 clients, however if the Redis server is not 1080 # able to configure the process file limit to allow for the specified limit 1081 # the max number of allowed clients is set to the current file limit 1082 # minus 32 (as Redis reserves a few file descriptors for internal uses). 1083 # 1084 # Once the limit is reached Redis will close all the new connections sending 1085 # an error 'max number of clients reached'. 1086 # 1087 # IMPORTANT: When Redis Cluster is used, the max number of connections is also 1088 # shared with the cluster bus: every node in the cluster will use two 1089 # connections, one incoming and another outgoing. It is important to size the 1090 # limit accordingly in case of very large clusters. 1091 # 1092 # maxclients 10000 1093 1094 ############################## MEMORY MANAGEMENT ################################ 1095 1096 # Set a memory usage limit to the specified amount of bytes. 1097 # When the memory limit is reached Redis will try to remove keys 1098 # according to the eviction policy selected (see maxmemory-policy). 1099 # 1100 # If Redis can't remove keys according to the policy, or if the policy is 1101 # set to 'noeviction', Redis will start to reply with errors to commands 1102 # that would use more memory, like SET, LPUSH, and so on, and will continue 1103 # to reply to read-only commands like GET. 1104 # 1105 # This option is usually useful when using Redis as an LRU or LFU cache, or to 1106 # set a hard memory limit for an instance (using the 'noeviction' policy). 1107 # 1108 # WARNING: If you have replicas attached to an instance with maxmemory on, 1109 # the size of the output buffers needed to feed the replicas are subtracted 1110 # from the used memory count, so that network problems / resyncs will 1111 # not trigger a loop where keys are evicted, and in turn the output 1112 # buffer of replicas is full with DELs of keys evicted triggering the deletion 1113 # of more keys, and so forth until the database is completely emptied. 1114 # 1115 # In short... if you have replicas attached it is suggested that you set a lower 1116 # limit for maxmemory so that there is some free RAM on the system for replica 1117 # output buffers (but this is not needed if the policy is 'noeviction'). 1118 # 1119 # maxmemory <bytes> 1120 1121 # MAXMEMORY POLICY: how Redis will select what to remove when maxmemory 1122 # is reached. You can select one from the following behaviors: 1123 # 1124 # volatile-lru -> Evict using approximated LRU, only keys with an expire set. 1125 # allkeys-lru -> Evict any key using approximated LRU. 1126 # volatile-lfu -> Evict using approximated LFU, only keys with an expire set. 1127 # allkeys-lfu -> Evict any key using approximated LFU. 1128 # volatile-random -> Remove a random key having an expire set. 1129 # allkeys-random -> Remove a random key, any key. 1130 # volatile-ttl -> Remove the key with the nearest expire time (minor TTL) 1131 # noeviction -> Don't evict anything, just return an error on write operations. 1132 # 1133 # LRU means Least Recently Used 1134 # LFU means Least Frequently Used 1135 # 1136 # Both LRU, LFU and volatile-ttl are implemented using approximated 1137 # randomized algorithms. 1138 # 1139 # Note: with any of the above policies, when there are no suitable keys for 1140 # eviction, Redis will return an error on write operations that require 1141 # more memory. These are usually commands that create new keys, add data or 1142 # modify existing keys. A few examples are: SET, INCR, HSET, LPUSH, SUNIONSTORE, 1143 # SORT (due to the STORE argument), and EXEC (if the transaction includes any 1144 # command that requires memory). 1145 # 1146 # The default is: 1147 # 1148 # maxmemory-policy noeviction 1149 1150 # LRU, LFU and minimal TTL algorithms are not precise algorithms but approximated 1151 # algorithms (in order to save memory), so you can tune it for speed or 1152 # accuracy. By default Redis will check five keys and pick the one that was 1153 # used least recently, you can change the sample size using the following 1154 # configuration directive. 1155 # 1156 # The default of 5 produces good enough results. 10 Approximates very closely 1157 # true LRU but costs more CPU. 3 is faster but not very accurate. 1158 # 1159 # maxmemory-samples 5 1160 1161 # Eviction processing is designed to function well with the default setting. 1162 # If there is an unusually large amount of write traffic, this value may need to 1163 # be increased. Decreasing this value may reduce latency at the risk of 1164 # eviction processing effectiveness 1165 # 0 = minimum latency, 10 = default, 100 = process without regard to latency 1166 # 1167 # maxmemory-eviction-tenacity 10 1168 1169 # Starting from Redis 5, by default a replica will ignore its maxmemory setting 1170 # (unless it is promoted to master after a failover or manually). It means 1171 # that the eviction of keys will be just handled by the master, sending the 1172 # DEL commands to the replica as keys evict in the master side. 1173 # 1174 # This behavior ensures that masters and replicas stay consistent, and is usually 1175 # what you want, however if your replica is writable, or you want the replica 1176 # to have a different memory setting, and you are sure all the writes performed 1177 # to the replica are idempotent, then you may change this default (but be sure 1178 # to understand what you are doing). 1179 # 1180 # Note that since the replica by default does not evict, it may end using more 1181 # memory than the one set via maxmemory (there are certain buffers that may 1182 # be larger on the replica, or data structures may sometimes take more memory 1183 # and so forth). So make sure you monitor your replicas and make sure they 1184 # have enough memory to never hit a real out-of-memory condition before the 1185 # master hits the configured maxmemory setting. 1186 # 1187 # replica-ignore-maxmemory yes 1188 1189 # Redis reclaims expired keys in two ways: upon access when those keys are 1190 # found to be expired, and also in background, in what is called the 1191 # "active expire key". The key space is slowly and interactively scanned 1192 # looking for expired keys to reclaim, so that it is possible to free memory 1193 # of keys that are expired and will never be accessed again in a short time. 1194 # 1195 # The default effort of the expire cycle will try to avoid having more than 1196 # ten percent of expired keys still in memory, and will try to avoid consuming 1197 # more than 25% of total memory and to add latency to the system. However 1198 # it is possible to increase the expire "effort" that is normally set to 1199 # "1", to a greater value, up to the value "10". At its maximum value the 1200 # system will use more CPU, longer cycles (and technically may introduce 1201 # more latency), and will tolerate less already expired keys still present 1202 # in the system. It's a tradeoff between memory, CPU and latency. 1203 # 1204 # active-expire-effort 1 1205 1206 ############################# LAZY FREEING #################################### 1207 1208 # Redis has two primitives to delete keys. One is called DEL and is a blocking 1209 # deletion of the object. It means that the server stops processing new commands 1210 # in order to reclaim all the memory associated with an object in a synchronous 1211 # way. If the key deleted is associated with a small object, the time needed 1212 # in order to execute the DEL command is very small and comparable to most other 1213 # O(1) or O(log_N) commands in Redis. However if the key is associated with an 1214 # aggregated value containing millions of elements, the server can block for 1215 # a long time (even seconds) in order to complete the operation. 1216 # 1217 # For the above reasons Redis also offers non blocking deletion primitives 1218 # such as UNLINK (non blocking DEL) and the ASYNC option of FLUSHALL and 1219 # FLUSHDB commands, in order to reclaim memory in background. Those commands 1220 # are executed in constant time. Another thread will incrementally free the 1221 # object in the background as fast as possible. 1222 # 1223 # DEL, UNLINK and ASYNC option of FLUSHALL and FLUSHDB are user-controlled. 1224 # It's up to the design of the application to understand when it is a good 1225 # idea to use one or the other. However the Redis server sometimes has to 1226 # delete keys or flush the whole database as a side effect of other operations. 1227 # Specifically Redis deletes objects independently of a user call in the 1228 # following scenarios: 1229 # 1230 # 1) On eviction, because of the maxmemory and maxmemory policy configurations, 1231 # in order to make room for new data, without going over the specified 1232 # memory limit. 1233 # 2) Because of expire: when a key with an associated time to live (see the 1234 # EXPIRE command) must be deleted from memory. 1235 # 3) Because of a side effect of a command that stores data on a key that may 1236 # already exist. For example the RENAME command may delete the old key 1237 # content when it is replaced with another one. Similarly SUNIONSTORE 1238 # or SORT with STORE option may delete existing keys. The SET command 1239 # itself removes any old content of the specified key in order to replace 1240 # it with the specified string. 1241 # 4) During replication, when a replica performs a full resynchronization with 1242 # its master, the content of the whole database is removed in order to 1243 # load the RDB file just transferred. 1244 # 1245 # In all the above cases the default is to delete objects in a blocking way, 1246 # like if DEL was called. However you can configure each case specifically 1247 # in order to instead release memory in a non-blocking way like if UNLINK 1248 # was called, using the following configuration directives. 1249 1250 lazyfree-lazy-eviction no 1251 lazyfree-lazy-expire no 1252 lazyfree-lazy-server-del no 1253 replica-lazy-flush no 1254 1255 # It is also possible, for the case when to replace the user code DEL calls 1256 # with UNLINK calls is not easy, to modify the default behavior of the DEL 1257 # command to act exactly like UNLINK, using the following configuration 1258 # directive: 1259 1260 lazyfree-lazy-user-del no 1261 1262 # FLUSHDB, FLUSHALL, SCRIPT FLUSH and FUNCTION FLUSH support both asynchronous and synchronous 1263 # deletion, which can be controlled by passing the [SYNC|ASYNC] flags into the 1264 # commands. When neither flag is passed, this directive will be used to determine 1265 # if the data should be deleted asynchronously. 1266 1267 lazyfree-lazy-user-flush no 1268 1269 ################################ THREADED I/O ################################# 1270 1271 # Redis is mostly single threaded, however there are certain threaded 1272 # operations such as UNLINK, slow I/O accesses and other things that are 1273 # performed on side threads. 1274 # 1275 # Now it is also possible to handle Redis clients socket reads and writes 1276 # in different I/O threads. Since especially writing is so slow, normally 1277 # Redis users use pipelining in order to speed up the Redis performances per 1278 # core, and spawn multiple instances in order to scale more. Using I/O 1279 # threads it is possible to easily speedup two times Redis without resorting 1280 # to pipelining nor sharding of the instance. 1281 # 1282 # By default threading is disabled, we suggest enabling it only in machines 1283 # that have at least 4 or more cores, leaving at least one spare core. 1284 # Using more than 8 threads is unlikely to help much. We also recommend using 1285 # threaded I/O only if you actually have performance problems, with Redis 1286 # instances being able to use a quite big percentage of CPU time, otherwise 1287 # there is no point in using this feature. 1288 # 1289 # So for instance if you have a four cores boxes, try to use 2 or 3 I/O 1290 # threads, if you have a 8 cores, try to use 6 threads. In order to 1291 # enable I/O threads use the following configuration directive: 1292 # 1293 # io-threads 4 1294 # 1295 # Setting io-threads to 1 will just use the main thread as usual. 1296 # When I/O threads are enabled, we only use threads for writes, that is 1297 # to thread the write(2) syscall and transfer the client buffers to the 1298 # socket. However it is also possible to enable threading of reads and 1299 # protocol parsing using the following configuration directive, by setting 1300 # it to yes: 1301 # 1302 # io-threads-do-reads no 1303 # 1304 # Usually threading reads doesn't help much. 1305 # 1306 # NOTE 1: This configuration directive cannot be changed at runtime via 1307 # CONFIG SET. Also, this feature currently does not work when SSL is 1308 # enabled. 1309 # 1310 # NOTE 2: If you want to test the Redis speedup using redis-benchmark, make 1311 # sure you also run the benchmark itself in threaded mode, using the 1312 # --threads option to match the number of Redis threads, otherwise you'll not 1313 # be able to notice the improvements. 1314 1315 ############################ KERNEL OOM CONTROL ############################## 1316 1317 # On Linux, it is possible to hint the kernel OOM killer on what processes 1318 # should be killed first when out of memory. 1319 # 1320 # Enabling this feature makes Redis actively control the oom_score_adj value 1321 # for all its processes, depending on their role. The default scores will 1322 # attempt to have background child processes killed before all others, and 1323 # replicas killed before masters. 1324 # 1325 # Redis supports these options: 1326 # 1327 # no: Don't make changes to oom-score-adj (default). 1328 # yes: Alias to "relative" see below. 1329 # absolute: Values in oom-score-adj-values are written as is to the kernel. 1330 # relative: Values are used relative to the initial value of oom_score_adj when 1331 # the server starts and are then clamped to a range of -1000 to 1000. 1332 # Because typically the initial value is 0, they will often match the 1333 # absolute values. 1334 oom-score-adj no 1335 1336 # When oom-score-adj is used, this directive controls the specific values used 1337 # for master, replica and background child processes. Values range -2000 to 1338 # 2000 (higher means more likely to be killed). 1339 # 1340 # Unprivileged processes (not root, and without CAP_SYS_RESOURCE capabilities) 1341 # can freely increase their value, but not decrease it below its initial 1342 # settings. This means that setting oom-score-adj to "relative" and setting the 1343 # oom-score-adj-values to positive values will always succeed. 1344 oom-score-adj-values 0 200 800 1345 1346 1347 #################### KERNEL transparent hugepage CONTROL ###################### 1348 1349 # Usually the kernel Transparent Huge Pages control is set to "madvise" or 1350 # or "never" by default (/sys/kernel/mm/transparent_hugepage/enabled), in which 1351 # case this config has no effect. On systems in which it is set to "always", 1352 # redis will attempt to disable it specifically for the redis process in order 1353 # to avoid latency problems specifically with fork(2) and CoW. 1354 # If for some reason you prefer to keep it enabled, you can set this config to 1355 # "no" and the kernel global to "always". 1356 1357 disable-thp yes 1358 1359 ############################## APPEND ONLY MODE ############################### 1360 1361 # By default Redis asynchronously dumps the dataset on disk. This mode is 1362 # good enough in many applications, but an issue with the Redis process or 1363 # a power outage may result into a few minutes of writes lost (depending on 1364 # the configured save points). 1365 # 1366 # The Append Only File is an alternative persistence mode that provides 1367 # much better durability. For instance using the default data fsync policy 1368 # (see later in the config file) Redis can lose just one second of writes in a 1369 # dramatic event like a server power outage, or a single write if something 1370 # wrong with the Redis process itself happens, but the operating system is 1371 # still running correctly. 1372 # 1373 # AOF and RDB persistence can be enabled at the same time without problems. 1374 # If the AOF is enabled on startup Redis will load the AOF, that is the file 1375 # with the better durability guarantees. 1376 # 1377 # Please check https://redis.io/topics/persistence for more information. 1378 1379 appendonly no 1380 1381 # The base name of the append only file. 1382 # 1383 # Redis 7 and newer use a set of append-only files to persist the dataset 1384 # and changes applied to it. There are two basic types of files in use: 1385 # 1386 # - Base files, which are a snapshot representing the complete state of the 1387 # dataset at the time the file was created. Base files can be either in 1388 # the form of RDB (binary serialized) or AOF (textual commands). 1389 # - Incremental files, which contain additional commands that were applied 1390 # to the dataset following the previous file. 1391 # 1392 # In addition, manifest files are used to track the files and the order in 1393 # which they were created and should be applied. 1394 # 1395 # Append-only file names are created by Redis following a specific pattern. 1396 # The file name's prefix is based on the 'appendfilename' configuration 1397 # parameter, followed by additional information about the sequence and type. 1398 # 1399 # For example, if appendfilename is set to appendonly.aof, the following file 1400 # names could be derived: 1401 # 1402 # - appendonly.aof.1.base.rdb as a base file. 1403 # - appendonly.aof.1.incr.aof, appendonly.aof.2.incr.aof as incremental files. 1404 # - appendonly.aof.manifest as a manifest file. 1405 1406 appendfilename "appendonly.aof" 1407 1408 # For convenience, Redis stores all persistent append-only files in a dedicated 1409 # directory. The name of the directory is determined by the appenddirname 1410 # configuration parameter. 1411 1412 appenddirname "appendonlydir" 1413 1414 # The fsync() call tells the Operating System to actually write data on disk 1415 # instead of waiting for more data in the output buffer. Some OS will really flush 1416 # data on disk, some other OS will just try to do it ASAP. 1417 # 1418 # Redis supports three different modes: 1419 # 1420 # no: don't fsync, just let the OS flush the data when it wants. Faster. 1421 # always: fsync after every write to the append only log. Slow, Safest. 1422 # everysec: fsync only one time every second. Compromise. 1423 # 1424 # The default is "everysec", as that's usually the right compromise between 1425 # speed and data safety. It's up to you to understand if you can relax this to 1426 # "no" that will let the operating system flush the output buffer when 1427 # it wants, for better performances (but if you can live with the idea of 1428 # some data loss consider the default persistence mode that's snapshotting), 1429 # or on the contrary, use "always" that's very slow but a bit safer than 1430 # everysec. 1431 # 1432 # More details please check the following article: 1433 # http://antirez.com/post/redis-persistence-demystified.html 1434 # 1435 # If unsure, use "everysec". 1436 1437 # appendfsync always 1438 appendfsync everysec 1439 # appendfsync no 1440 1441 # When the AOF fsync policy is set to always or everysec, and a background 1442 # saving process (a background save or AOF log background rewriting) is 1443 # performing a lot of I/O against the disk, in some Linux configurations 1444 # Redis may block too long on the fsync() call. Note that there is no fix for 1445 # this currently, as even performing fsync in a different thread will block 1446 # our synchronous write(2) call. 1447 # 1448 # In order to mitigate this problem it's possible to use the following option 1449 # that will prevent fsync() from being called in the main process while a 1450 # BGSAVE or BGREWRITEAOF is in progress. 1451 # 1452 # This means that while another child is saving, the durability of Redis is 1453 # the same as "appendfsync no". In practical terms, this means that it is 1454 # possible to lose up to 30 seconds of log in the worst scenario (with the 1455 # default Linux settings). 1456 # 1457 # If you have latency problems turn this to "yes". Otherwise leave it as 1458 # "no" that is the safest pick from the point of view of durability. 1459 1460 no-appendfsync-on-rewrite no 1461 1462 # Automatic rewrite of the append only file. 1463 # Redis is able to automatically rewrite the log file implicitly calling 1464 # BGREWRITEAOF when the AOF log size grows by the specified percentage. 1465 # 1466 # This is how it works: Redis remembers the size of the AOF file after the 1467 # latest rewrite (if no rewrite has happened since the restart, the size of 1468 # the AOF at startup is used). 1469 # 1470 # This base size is compared to the current size. If the current size is 1471 # bigger than the specified percentage, the rewrite is triggered. Also 1472 # you need to specify a minimal size for the AOF file to be rewritten, this 1473 # is useful to avoid rewriting the AOF file even if the percentage increase 1474 # is reached but it is still pretty small. 1475 # 1476 # Specify a percentage of zero in order to disable the automatic AOF 1477 # rewrite feature. 1478 1479 auto-aof-rewrite-percentage 100 1480 auto-aof-rewrite-min-size 64mb 1481 1482 # An AOF file may be found to be truncated at the end during the Redis 1483 # startup process, when the AOF data gets loaded back into memory. 1484 # This may happen when the system where Redis is running 1485 # crashes, especially when an ext4 filesystem is mounted without the 1486 # data=ordered option (however this can't happen when Redis itself 1487 # crashes or aborts but the operating system still works correctly). 1488 # 1489 # Redis can either exit with an error when this happens, or load as much 1490 # data as possible (the default now) and start if the AOF file is found 1491 # to be truncated at the end. The following option controls this behavior. 1492 # 1493 # If aof-load-truncated is set to yes, a truncated AOF file is loaded and 1494 # the Redis server starts emitting a log to inform the user of the event. 1495 # Otherwise if the option is set to no, the server aborts with an error 1496 # and refuses to start. When the option is set to no, the user requires 1497 # to fix the AOF file using the "redis-check-aof" utility before to restart 1498 # the server. 1499 # 1500 # Note that if the AOF file will be found to be corrupted in the middle 1501 # the server will still exit with an error. This option only applies when 1502 # Redis will try to read more data from the AOF file but not enough bytes 1503 # will be found. 1504 aof-load-truncated yes 1505 1506 # Redis can create append-only base files in either RDB or AOF formats. Using 1507 # the RDB format is always faster and more efficient, and disabling it is only 1508 # supported for backward compatibility purposes. 1509 aof-use-rdb-preamble yes 1510 1511 # Redis supports recording timestamp annotations in the AOF to support restoring 1512 # the data from a specific point-in-time. However, using this capability changes 1513 # the AOF format in a way that may not be compatible with existing AOF parsers. 1514 aof-timestamp-enabled no 1515 1516 ################################ SHUTDOWN ##################################### 1517 1518 # Maximum time to wait for replicas when shutting down, in seconds. 1519 # 1520 # During shut down, a grace period allows any lagging replicas to catch up with 1521 # the latest replication offset before the master exists. This period can 1522 # prevent data loss, especially for deployments without configured disk backups. 1523 # 1524 # The 'shutdown-timeout' value is the grace period's duration in seconds. It is 1525 # only applicable when the instance has replicas. To disable the feature, set 1526 # the value to 0. 1527 # 1528 # shutdown-timeout 10 1529 1530 # When Redis receives a SIGINT or SIGTERM, shutdown is initiated and by default 1531 # an RDB snapshot is written to disk in a blocking operation if save points are configured. 1532 # The options used on signaled shutdown can include the following values: 1533 # default: Saves RDB snapshot only if save points are configured. 1534 # Waits for lagging replicas to catch up. 1535 # save: Forces a DB saving operation even if no save points are configured. 1536 # nosave: Prevents DB saving operation even if one or more save points are configured. 1537 # now: Skips waiting for lagging replicas. 1538 # force: Ignores any errors that would normally prevent the server from exiting. 1539 # 1540 # Any combination of values is allowed as long as "save" and "nosave" are not set simultaneously. 1541 # Example: "nosave force now" 1542 # 1543 # shutdown-on-sigint default 1544 # shutdown-on-sigterm default 1545 1546 ################ NON-DETERMINISTIC LONG BLOCKING COMMANDS ##################### 1547 1548 # Maximum time in milliseconds for EVAL scripts, functions and in some cases 1549 # modules' commands before Redis can start processing or rejecting other clients. 1550 # 1551 # If the maximum execution time is reached Redis will start to reply to most 1552 # commands with a BUSY error. 1553 # 1554 # In this state Redis will only allow a handful of commands to be executed. 1555 # For instance, SCRIPT KILL, FUNCTION KILL, SHUTDOWN NOSAVE and possibly some 1556 # module specific 'allow-busy' commands. 1557 # 1558 # SCRIPT KILL and FUNCTION KILL will only be able to stop a script that did not 1559 # yet call any write commands, so SHUTDOWN NOSAVE may be the only way to stop 1560 # the server in the case a write command was already issued by the script when 1561 # the user doesn't want to wait for the natural termination of the script. 1562 # 1563 # The default is 5 seconds. It is possible to set it to 0 or a negative value 1564 # to disable this mechanism (uninterrupted execution). Note that in the past 1565 # this config had a different name, which is now an alias, so both of these do 1566 # the same: 1567 # lua-time-limit 5000 1568 # busy-reply-threshold 5000 1569 1570 ################################ REDIS CLUSTER ############################### 1571 1572 # Normal Redis instances can't be part of a Redis Cluster; only nodes that are 1573 # started as cluster nodes can. In order to start a Redis instance as a 1574 # cluster node enable the cluster support uncommenting the following: 1575 # 1576 # cluster-enabled yes 1577 1578 # Every cluster node has a cluster configuration file. This file is not 1579 # intended to be edited by hand. It is created and updated by Redis nodes. 1580 # Every Redis Cluster node requires a different cluster configuration file. 1581 # Make sure that instances running in the same system do not have 1582 # overlapping cluster configuration file names. 1583 # 1584 # cluster-config-file nodes-6379.conf 1585 1586 # Cluster node timeout is the amount of milliseconds a node must be unreachable 1587 # for it to be considered in failure state. 1588 # Most other internal time limits are a multiple of the node timeout. 1589 # 1590 # cluster-node-timeout 15000 1591 1592 # The cluster port is the port that the cluster bus will listen for inbound connections on. When set 1593 # to the default value, 0, it will be bound to the command port + 10000. Setting this value requires 1594 # you to specify the cluster bus port when executing cluster meet. 1595 # cluster-port 0 1596 1597 # A replica of a failing master will avoid to start a failover if its data 1598 # looks too old. 1599 # 1600 # There is no simple way for a replica to actually have an exact measure of 1601 # its "data age", so the following two checks are performed: 1602 # 1603 # 1) If there are multiple replicas able to failover, they exchange messages 1604 # in order to try to give an advantage to the replica with the best 1605 # replication offset (more data from the master processed). 1606 # Replicas will try to get their rank by offset, and apply to the start 1607 # of the failover a delay proportional to their rank. 1608 # 1609 # 2) Every single replica computes the time of the last interaction with 1610 # its master. This can be the last ping or command received (if the master 1611 # is still in the "connected" state), or the time that elapsed since the 1612 # disconnection with the master (if the replication link is currently down). 1613 # If the last interaction is too old, the replica will not try to failover 1614 # at all. 1615 # 1616 # The point "2" can be tuned by user. Specifically a replica will not perform 1617 # the failover if, since the last interaction with the master, the time 1618 # elapsed is greater than: 1619 # 1620 # (node-timeout * cluster-replica-validity-factor) + repl-ping-replica-period 1621 # 1622 # So for example if node-timeout is 30 seconds, and the cluster-replica-validity-factor 1623 # is 10, and assuming a default repl-ping-replica-period of 10 seconds, the 1624 # replica will not try to failover if it was not able to talk with the master 1625 # for longer than 310 seconds. 1626 # 1627 # A large cluster-replica-validity-factor may allow replicas with too old data to failover 1628 # a master, while a too small value may prevent the cluster from being able to 1629 # elect a replica at all. 1630 # 1631 # For maximum availability, it is possible to set the cluster-replica-validity-factor 1632 # to a value of 0, which means, that replicas will always try to failover the 1633 # master regardless of the last time they interacted with the master. 1634 # (However they'll always try to apply a delay proportional to their 1635 # offset rank). 1636 # 1637 # Zero is the only value able to guarantee that when all the partitions heal 1638 # the cluster will always be able to continue. 1639 # 1640 # cluster-replica-validity-factor 10 1641 1642 # Cluster replicas are able to migrate to orphaned masters, that are masters 1643 # that are left without working replicas. This improves the cluster ability 1644 # to resist to failures as otherwise an orphaned master can't be failed over 1645 # in case of failure if it has no working replicas. 1646 # 1647 # Replicas migrate to orphaned masters only if there are still at least a 1648 # given number of other working replicas for their old master. This number 1649 # is the "migration barrier". A migration barrier of 1 means that a replica 1650 # will migrate only if there is at least 1 other working replica for its master 1651 # and so forth. It usually reflects the number of replicas you want for every 1652 # master in your cluster. 1653 # 1654 # Default is 1 (replicas migrate only if their masters remain with at least 1655 # one replica). To disable migration just set it to a very large value or 1656 # set cluster-allow-replica-migration to 'no'. 1657 # A value of 0 can be set but is useful only for debugging and dangerous 1658 # in production. 1659 # 1660 # cluster-migration-barrier 1 1661 1662 # Turning off this option allows to use less automatic cluster configuration. 1663 # It both disables migration to orphaned masters and migration from masters 1664 # that became empty. 1665 # 1666 # Default is 'yes' (allow automatic migrations). 1667 # 1668 # cluster-allow-replica-migration yes 1669 1670 # By default Redis Cluster nodes stop accepting queries if they detect there 1671 # is at least a hash slot uncovered (no available node is serving it). 1672 # This way if the cluster is partially down (for example a range of hash slots 1673 # are no longer covered) all the cluster becomes, eventually, unavailable. 1674 # It automatically returns available as soon as all the slots are covered again. 1675 # 1676 # However sometimes you want the subset of the cluster which is working, 1677 # to continue to accept queries for the part of the key space that is still 1678 # covered. In order to do so, just set the cluster-require-full-coverage 1679 # option to no. 1680 # 1681 # cluster-require-full-coverage yes 1682 1683 # This option, when set to yes, prevents replicas from trying to failover its 1684 # master during master failures. However the replica can still perform a 1685 # manual failover, if forced to do so. 1686 # 1687 # This is useful in different scenarios, especially in the case of multiple 1688 # data center operations, where we want one side to never be promoted if not 1689 # in the case of a total DC failure. 1690 # 1691 # cluster-replica-no-failover no 1692 1693 # This option, when set to yes, allows nodes to serve read traffic while the 1694 # cluster is in a down state, as long as it believes it owns the slots. 1695 # 1696 # This is useful for two cases. The first case is for when an application 1697 # doesn't require consistency of data during node failures or network partitions. 1698 # One example of this is a cache, where as long as the node has the data it 1699 # should be able to serve it. 1700 # 1701 # The second use case is for configurations that don't meet the recommended 1702 # three shards but want to enable cluster mode and scale later. A 1703 # master outage in a 1 or 2 shard configuration causes a read/write outage to the 1704 # entire cluster without this option set, with it set there is only a write outage. 1705 # Without a quorum of masters, slot ownership will not change automatically. 1706 # 1707 # cluster-allow-reads-when-down no 1708 1709 # This option, when set to yes, allows nodes to serve pubsub shard traffic while 1710 # the cluster is in a down state, as long as it believes it owns the slots. 1711 # 1712 # This is useful if the application would like to use the pubsub feature even when 1713 # the cluster global stable state is not OK. If the application wants to make sure only 1714 # one shard is serving a given channel, this feature should be kept as yes. 1715 # 1716 # cluster-allow-pubsubshard-when-down yes 1717 1718 # Cluster link send buffer limit is the limit on the memory usage of an individual 1719 # cluster bus link's send buffer in bytes. Cluster links would be freed if they exceed 1720 # this limit. This is to primarily prevent send buffers from growing unbounded on links 1721 # toward slow peers (E.g. PubSub messages being piled up). 1722 # This limit is disabled by default. Enable this limit when 'mem_cluster_links' INFO field 1723 # and/or 'send-buffer-allocated' entries in the 'CLUSTER LINKS` command output continuously increase. 1724 # Minimum limit of 1gb is recommended so that cluster link buffer can fit in at least a single 1725 # PubSub message by default. (client-query-buffer-limit default value is 1gb) 1726 # 1727 # cluster-link-sendbuf-limit 0 1728 1729 # Clusters can configure their announced hostname using this config. This is a common use case for 1730 # applications that need to use TLS Server Name Indication (SNI) or dealing with DNS based 1731 # routing. By default this value is only shown as additional metadata in the CLUSTER SLOTS 1732 # command, but can be changed using 'cluster-preferred-endpoint-type' config. This value is 1733 # communicated along the clusterbus to all nodes, setting it to an empty string will remove 1734 # the hostname and also propagate the removal. 1735 # 1736 # cluster-announce-hostname "" 1737 1738 # Clusters can advertise how clients should connect to them using either their IP address, 1739 # a user defined hostname, or by declaring they have no endpoint. Which endpoint is 1740 # shown as the preferred endpoint is set by using the cluster-preferred-endpoint-type 1741 # config with values 'ip', 'hostname', or 'unknown-endpoint'. This value controls how 1742 # the endpoint returned for MOVED/ASKING requests as well as the first field of CLUSTER SLOTS. 1743 # If the preferred endpoint type is set to hostname, but no announced hostname is set, a '?' 1744 # will be returned instead. 1745 # 1746 # When a cluster advertises itself as having an unknown endpoint, it's indicating that 1747 # the server doesn't know how clients can reach the cluster. This can happen in certain 1748 # networking situations where there are multiple possible routes to the node, and the 1749 # server doesn't know which one the client took. In this case, the server is expecting 1750 # the client to reach out on the same endpoint it used for making the last request, but use 1751 # the port provided in the response. 1752 # 1753 # cluster-preferred-endpoint-type ip 1754 1755 # In order to setup your cluster make sure to read the documentation 1756 # available at https://redis.io web site. 1757 1758 ########################## CLUSTER DOCKER/NAT support ######################## 1759 1760 # In certain deployments, Redis Cluster nodes address discovery fails, because 1761 # addresses are NAT-ted or because ports are forwarded (the typical case is 1762 # Docker and other containers). 1763 # 1764 # In order to make Redis Cluster working in such environments, a static 1765 # configuration where each node knows its public address is needed. The 1766 # following four options are used for this scope, and are: 1767 # 1768 # * cluster-announce-ip 1769 # * cluster-announce-port 1770 # * cluster-announce-tls-port 1771 # * cluster-announce-bus-port 1772 # 1773 # Each instructs the node about its address, client ports (for connections 1774 # without and with TLS) and cluster message bus port. The information is then 1775 # published in the header of the bus packets so that other nodes will be able to 1776 # correctly map the address of the node publishing the information. 1777 # 1778 # If cluster-tls is set to yes and cluster-announce-tls-port is omitted or set 1779 # to zero, then cluster-announce-port refers to the TLS port. Note also that 1780 # cluster-announce-tls-port has no effect if cluster-tls is set to no. 1781 # 1782 # If the above options are not used, the normal Redis Cluster auto-detection 1783 # will be used instead. 1784 # 1785 # Note that when remapped, the bus port may not be at the fixed offset of 1786 # clients port + 10000, so you can specify any port and bus-port depending 1787 # on how they get remapped. If the bus-port is not set, a fixed offset of 1788 # 10000 will be used as usual. 1789 # 1790 # Example: 1791 # 1792 # cluster-announce-ip 10.1.1.5 1793 # cluster-announce-tls-port 6379 1794 # cluster-announce-port 0 1795 # cluster-announce-bus-port 6380 1796 1797 ################################## SLOW LOG ################################### 1798 1799 # The Redis Slow Log is a system to log queries that exceeded a specified 1800 # execution time. The execution time does not include the I/O operations 1801 # like talking with the client, sending the reply and so forth, 1802 # but just the time needed to actually execute the command (this is the only 1803 # stage of command execution where the thread is blocked and can not serve 1804 # other requests in the meantime). 1805 # 1806 # You can configure the slow log with two parameters: one tells Redis 1807 # what is the execution time, in microseconds, to exceed in order for the 1808 # command to get logged, and the other parameter is the length of the 1809 # slow log. When a new command is logged the oldest one is removed from the 1810 # queue of logged commands. 1811 1812 # The following time is expressed in microseconds, so 1000000 is equivalent 1813 # to one second. Note that a negative number disables the slow log, while 1814 # a value of zero forces the logging of every command. 1815 slowlog-log-slower-than 10000 1816 1817 # There is no limit to this length. Just be aware that it will consume memory. 1818 # You can reclaim memory used by the slow log with SLOWLOG RESET. 1819 slowlog-max-len 128 1820 1821 ################################ LATENCY MONITOR ############################## 1822 1823 # The Redis latency monitoring subsystem samples different operations 1824 # at runtime in order to collect data related to possible sources of 1825 # latency of a Redis instance. 1826 # 1827 # Via the LATENCY command this information is available to the user that can 1828 # print graphs and obtain reports. 1829 # 1830 # The system only logs operations that were performed in a time equal or 1831 # greater than the amount of milliseconds specified via the 1832 # latency-monitor-threshold configuration directive. When its value is set 1833 # to zero, the latency monitor is turned off. 1834 # 1835 # By default latency monitoring is disabled since it is mostly not needed 1836 # if you don't have latency issues, and collecting data has a performance 1837 # impact, that while very small, can be measured under big load. Latency 1838 # monitoring can easily be enabled at runtime using the command 1839 # "CONFIG SET latency-monitor-threshold <milliseconds>" if needed. 1840 latency-monitor-threshold 0 1841 1842 ################################ LATENCY TRACKING ############################## 1843 1844 # The Redis extended latency monitoring tracks the per command latencies and enables 1845 # exporting the percentile distribution via the INFO latencystats command, 1846 # and cumulative latency distributions (histograms) via the LATENCY command. 1847 # 1848 # By default, the extended latency monitoring is enabled since the overhead 1849 # of keeping track of the command latency is very small. 1850 # latency-tracking yes 1851 1852 # By default the exported latency percentiles via the INFO latencystats command 1853 # are the p50, p99, and p999. 1854 # latency-tracking-info-percentiles 50 99 99.9 1855 1856 ############################# EVENT NOTIFICATION ############################## 1857 1858 # Redis can notify Pub/Sub clients about events happening in the key space. 1859 # This feature is documented at https://redis.io/topics/notifications 1860 # 1861 # For instance if keyspace events notification is enabled, and a client 1862 # performs a DEL operation on key "foo" stored in the Database 0, two 1863 # messages will be published via Pub/Sub: 1864 # 1865 # PUBLISH __keyspace@0__:foo del 1866 # PUBLISH __keyevent@0__:del foo 1867 # 1868 # It is possible to select the events that Redis will notify among a set 1869 # of classes. Every class is identified by a single character: 1870 # 1871 # K Keyspace events, published with __keyspace@<db>__ prefix. 1872 # E Keyevent events, published with __keyevent@<db>__ prefix. 1873 # g Generic commands (non-type specific) like DEL, EXPIRE, RENAME, ... 1874 # $ String commands 1875 # l List commands 1876 # s Set commands 1877 # h Hash commands 1878 # z Sorted set commands 1879 # x Expired events (events generated every time a key expires) 1880 # e Evicted events (events generated when a key is evicted for maxmemory) 1881 # n New key events (Note: not included in the 'A' class) 1882 # t Stream commands 1883 # d Module key type events 1884 # m Key-miss events (Note: It is not included in the 'A' class) 1885 # A Alias for g$lshzxetd, so that the "AKE" string means all the events 1886 # (Except key-miss events which are excluded from 'A' due to their 1887 # unique nature). 1888 # 1889 # The "notify-keyspace-events" takes as argument a string that is composed 1890 # of zero or multiple characters. The empty string means that notifications 1891 # are disabled. 1892 # 1893 # Example: to enable list and generic events, from the point of view of the 1894 # event name, use: 1895 # 1896 # notify-keyspace-events Elg 1897 # 1898 # Example 2: to get the stream of the expired keys subscribing to channel 1899 # name __keyevent@0__:expired use: 1900 # 1901 # notify-keyspace-events Ex 1902 # 1903 # By default all notifications are disabled because most users don't need 1904 # this feature and the feature has some overhead. Note that if you don't 1905 # specify at least one of K or E, no events will be delivered. 1906 notify-keyspace-events "" 1907 1908 ############################### ADVANCED CONFIG ############################### 1909 1910 # Hashes are encoded using a memory efficient data structure when they have a 1911 # small number of entries, and the biggest entry does not exceed a given 1912 # threshold. These thresholds can be configured using the following directives. 1913 hash-max-listpack-entries 512 1914 hash-max-listpack-value 64 1915 1916 # Lists are also encoded in a special way to save a lot of space. 1917 # The number of entries allowed per internal list node can be specified 1918 # as a fixed maximum size or a maximum number of elements. 1919 # For a fixed maximum size, use -5 through -1, meaning: 1920 # -5: max size: 64 Kb <-- not recommended for normal workloads 1921 # -4: max size: 32 Kb <-- not recommended 1922 # -3: max size: 16 Kb <-- probably not recommended 1923 # -2: max size: 8 Kb <-- good 1924 # -1: max size: 4 Kb <-- good 1925 # Positive numbers mean store up to _exactly_ that number of elements 1926 # per list node. 1927 # The highest performing option is usually -2 (8 Kb size) or -1 (4 Kb size), 1928 # but if your use case is unique, adjust the settings as necessary. 1929 list-max-listpack-size -2 1930 1931 # Lists may also be compressed. 1932 # Compress depth is the number of quicklist ziplist nodes from *each* side of 1933 # the list to *exclude* from compression. The head and tail of the list 1934 # are always uncompressed for fast push/pop operations. Settings are: 1935 # 0: disable all list compression 1936 # 1: depth 1 means "don't start compressing until after 1 node into the list, 1937 # going from either the head or tail" 1938 # So: [head]->node->node->...->node->[tail] 1939 # [head], [tail] will always be uncompressed; inner nodes will compress. 1940 # 2: [head]->[next]->node->node->...->node->[prev]->[tail] 1941 # 2 here means: don't compress head or head->next or tail->prev or tail, 1942 # but compress all nodes between them. 1943 # 3: [head]->[next]->[next]->node->node->...->node->[prev]->[prev]->[tail] 1944 # etc. 1945 list-compress-depth 0 1946 1947 # Sets have a special encoding in just one case: when a set is composed 1948 # of just strings that happen to be integers in radix 10 in the range 1949 # of 64 bit signed integers. 1950 # The following configuration setting sets the limit in the size of the 1951 # set in order to use this special memory saving encoding. 1952 set-max-intset-entries 512 1953 1954 # Similarly to hashes and lists, sorted sets are also specially encoded in 1955 # order to save a lot of space. This encoding is only used when the length and 1956 # elements of a sorted set are below the following limits: 1957 zset-max-listpack-entries 128 1958 zset-max-listpack-value 64 1959 1960 # HyperLogLog sparse representation bytes limit. The limit includes the 1961 # 16 bytes header. When an HyperLogLog using the sparse representation crosses 1962 # this limit, it is converted into the dense representation. 1963 # 1964 # A value greater than 16000 is totally useless, since at that point the 1965 # dense representation is more memory efficient. 1966 # 1967 # The suggested value is ~ 3000 in order to have the benefits of 1968 # the space efficient encoding without slowing down too much PFADD, 1969 # which is O(N) with the sparse encoding. The value can be raised to 1970 # ~ 10000 when CPU is not a concern, but space is, and the data set is 1971 # composed of many HyperLogLogs with cardinality in the 0 - 15000 range. 1972 hll-sparse-max-bytes 3000 1973 1974 # Streams macro node max size / items. The stream data structure is a radix 1975 # tree of big nodes that encode multiple items inside. Using this configuration 1976 # it is possible to configure how big a single node can be in bytes, and the 1977 # maximum number of items it may contain before switching to a new node when 1978 # appending new stream entries. If any of the following settings are set to 1979 # zero, the limit is ignored, so for instance it is possible to set just a 1980 # max entries limit by setting max-bytes to 0 and max-entries to the desired 1981 # value. 1982 stream-node-max-bytes 4096 1983 stream-node-max-entries 100 1984 1985 # Active rehashing uses 1 millisecond every 100 milliseconds of CPU time in 1986 # order to help rehashing the main Redis hash table (the one mapping top-level 1987 # keys to values). The hash table implementation Redis uses (see dict.c) 1988 # performs a lazy rehashing: the more operation you run into a hash table 1989 # that is rehashing, the more rehashing "steps" are performed, so if the 1990 # server is idle the rehashing is never complete and some more memory is used 1991 # by the hash table. 1992 # 1993 # The default is to use this millisecond 10 times every second in order to 1994 # actively rehash the main dictionaries, freeing memory when possible. 1995 # 1996 # If unsure: 1997 # use "activerehashing no" if you have hard latency requirements and it is 1998 # not a good thing in your environment that Redis can reply from time to time 1999 # to queries with 2 milliseconds delay. 2000 # 2001 # use "activerehashing yes" if you don't have such hard requirements but 2002 # want to free memory asap when possible. 2003 activerehashing yes 2004 2005 # The client output buffer limits can be used to force disconnection of clients 2006 # that are not reading data from the server fast enough for some reason (a 2007 # common reason is that a Pub/Sub client can't consume messages as fast as the 2008 # publisher can produce them). 2009 # 2010 # The limit can be set differently for the three different classes of clients: 2011 # 2012 # normal -> normal clients including MONITOR clients 2013 # replica -> replica clients 2014 # pubsub -> clients subscribed to at least one pubsub channel or pattern 2015 # 2016 # The syntax of every client-output-buffer-limit directive is the following: 2017 # 2018 # client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds> 2019 # 2020 # A client is immediately disconnected once the hard limit is reached, or if 2021 # the soft limit is reached and remains reached for the specified number of 2022 # seconds (continuously). 2023 # So for instance if the hard limit is 32 megabytes and the soft limit is 2024 # 16 megabytes / 10 seconds, the client will get disconnected immediately 2025 # if the size of the output buffers reach 32 megabytes, but will also get 2026 # disconnected if the client reaches 16 megabytes and continuously overcomes 2027 # the limit for 10 seconds. 2028 # 2029 # By default normal clients are not limited because they don't receive data 2030 # without asking (in a push way), but just after a request, so only 2031 # asynchronous clients may create a scenario where data is requested faster 2032 # than it can read. 2033 # 2034 # Instead there is a default limit for pubsub and replica clients, since 2035 # subscribers and replicas receive data in a push fashion. 2036 # 2037 # Note that it doesn't make sense to set the replica clients output buffer 2038 # limit lower than the repl-backlog-size config (partial sync will succeed 2039 # and then replica will get disconnected). 2040 # Such a configuration is ignored (the size of repl-backlog-size will be used). 2041 # This doesn't have memory consumption implications since the replica client 2042 # will share the backlog buffers memory. 2043 # 2044 # Both the hard or the soft limit can be disabled by setting them to zero. 2045 client-output-buffer-limit normal 0 0 0 2046 client-output-buffer-limit replica 256mb 64mb 60 2047 client-output-buffer-limit pubsub 32mb 8mb 60 2048 2049 # Client query buffers accumulate new commands. They are limited to a fixed 2050 # amount by default in order to avoid that a protocol desynchronization (for 2051 # instance due to a bug in the client) will lead to unbound memory usage in 2052 # the query buffer. However you can configure it here if you have very special 2053 # needs, such us huge multi/exec requests or alike. 2054 # 2055 # client-query-buffer-limit 1gb 2056 2057 # In some scenarios client connections can hog up memory leading to OOM 2058 # errors or data eviction. To avoid this we can cap the accumulated memory 2059 # used by all client connections (all pubsub and normal clients). Once we 2060 # reach that limit connections will be dropped by the server freeing up 2061 # memory. The server will attempt to drop the connections using the most 2062 # memory first. We call this mechanism "client eviction". 2063 # 2064 # Client eviction is configured using the maxmemory-clients setting as follows: 2065 # 0 - client eviction is disabled (default) 2066 # 2067 # A memory value can be used for the client eviction threshold, 2068 # for example: 2069 # maxmemory-clients 1g 2070 # 2071 # A percentage value (between 1% and 100%) means the client eviction threshold 2072 # is based on a percentage of the maxmemory setting. For example to set client 2073 # eviction at 5% of maxmemory: 2074 # maxmemory-clients 5% 2075 2076 # In the Redis protocol, bulk requests, that are, elements representing single 2077 # strings, are normally limited to 512 mb. However you can change this limit 2078 # here, but must be 1mb or greater 2079 # 2080 # proto-max-bulk-len 512mb 2081 2082 # Redis calls an internal function to perform many background tasks, like 2083 # closing connections of clients in timeout, purging expired keys that are 2084 # never requested, and so forth. 2085 # 2086 # Not all tasks are performed with the same frequency, but Redis checks for 2087 # tasks to perform according to the specified "hz" value. 2088 # 2089 # By default "hz" is set to 10. Raising the value will use more CPU when 2090 # Redis is idle, but at the same time will make Redis more responsive when 2091 # there are many keys expiring at the same time, and timeouts may be 2092 # handled with more precision. 2093 # 2094 # The range is between 1 and 500, however a value over 100 is usually not 2095 # a good idea. Most users should use the default of 10 and raise this up to 2096 # 100 only in environments where very low latency is required. 2097 hz 10 2098 2099 # Normally it is useful to have an HZ value which is proportional to the 2100 # number of clients connected. This is useful in order, for instance, to 2101 # avoid too many clients are processed for each background task invocation 2102 # in order to avoid latency spikes. 2103 # 2104 # Since the default HZ value by default is conservatively set to 10, Redis 2105 # offers, and enables by default, the ability to use an adaptive HZ value 2106 # which will temporarily raise when there are many connected clients. 2107 # 2108 # When dynamic HZ is enabled, the actual configured HZ will be used 2109 # as a baseline, but multiples of the configured HZ value will be actually 2110 # used as needed once more clients are connected. In this way an idle 2111 # instance will use very little CPU time while a busy instance will be 2112 # more responsive. 2113 dynamic-hz yes 2114 2115 # When a child rewrites the AOF file, if the following option is enabled 2116 # the file will be fsync-ed every 4 MB of data generated. This is useful 2117 # in order to commit the file to the disk more incrementally and avoid 2118 # big latency spikes. 2119 aof-rewrite-incremental-fsync yes 2120 2121 # When redis saves RDB file, if the following option is enabled 2122 # the file will be fsync-ed every 4 MB of data generated. This is useful 2123 # in order to commit the file to the disk more incrementally and avoid 2124 # big latency spikes. 2125 rdb-save-incremental-fsync yes 2126 2127 # Redis LFU eviction (see maxmemory setting) can be tuned. However it is a good 2128 # idea to start with the default settings and only change them after investigating 2129 # how to improve the performances and how the keys LFU change over time, which 2130 # is possible to inspect via the OBJECT FREQ command. 2131 # 2132 # There are two tunable parameters in the Redis LFU implementation: the 2133 # counter logarithm factor and the counter decay time. It is important to 2134 # understand what the two parameters mean before changing them. 2135 # 2136 # The LFU counter is just 8 bits per key, it's maximum value is 255, so Redis 2137 # uses a probabilistic increment with logarithmic behavior. Given the value 2138 # of the old counter, when a key is accessed, the counter is incremented in 2139 # this way: 2140 # 2141 # 1. A random number R between 0 and 1 is extracted. 2142 # 2. A probability P is calculated as 1/(old_value*lfu_log_factor+1). 2143 # 3. The counter is incremented only if R < P. 2144 # 2145 # The default lfu-log-factor is 10. This is a table of how the frequency 2146 # counter changes with a different number of accesses with different 2147 # logarithmic factors: 2148 # 2149 # +--------+------------+------------+------------+------------+------------+ 2150 # | factor | 100 hits | 1000 hits | 100K hits | 1M hits | 10M hits | 2151 # +--------+------------+------------+------------+------------+------------+ 2152 # | 0 | 104 | 255 | 255 | 255 | 255 | 2153 # +--------+------------+------------+------------+------------+------------+ 2154 # | 1 | 18 | 49 | 255 | 255 | 255 | 2155 # +--------+------------+------------+------------+------------+------------+ 2156 # | 10 | 10 | 18 | 142 | 255 | 255 | 2157 # +--------+------------+------------+------------+------------+------------+ 2158 # | 100 | 8 | 11 | 49 | 143 | 255 | 2159 # +--------+------------+------------+------------+------------+------------+ 2160 # 2161 # NOTE: The above table was obtained by running the following commands: 2162 # 2163 # redis-benchmark -n 1000000 incr foo 2164 # redis-cli object freq foo 2165 # 2166 # NOTE 2: The counter initial value is 5 in order to give new objects a chance 2167 # to accumulate hits. 2168 # 2169 # The counter decay time is the time, in minutes, that must elapse in order 2170 # for the key counter to be divided by two (or decremented if it has a value 2171 # less <= 10). 2172 # 2173 # The default value for the lfu-decay-time is 1. A special value of 0 means to 2174 # decay the counter every time it happens to be scanned. 2175 # 2176 # lfu-log-factor 10 2177 # lfu-decay-time 1 2178 2179 ########################### ACTIVE DEFRAGMENTATION ####################### 2180 # 2181 # What is active defragmentation? 2182 # ------------------------------- 2183 # 2184 # Active (online) defragmentation allows a Redis server to compact the 2185 # spaces left between small allocations and deallocations of data in memory, 2186 # thus allowing to reclaim back memory. 2187 # 2188 # Fragmentation is a natural process that happens with every allocator (but 2189 # less so with Jemalloc, fortunately) and certain workloads. Normally a server 2190 # restart is needed in order to lower the fragmentation, or at least to flush 2191 # away all the data and create it again. However thanks to this feature 2192 # implemented by Oran Agra for Redis 4.0 this process can happen at runtime 2193 # in a "hot" way, while the server is running. 2194 # 2195 # Basically when the fragmentation is over a certain level (see the 2196 # configuration options below) Redis will start to create new copies of the 2197 # values in contiguous memory regions by exploiting certain specific Jemalloc 2198 # features (in order to understand if an allocation is causing fragmentation 2199 # and to allocate it in a better place), and at the same time, will release the 2200 # old copies of the data. This process, repeated incrementally for all the keys 2201 # will cause the fragmentation to drop back to normal values. 2202 # 2203 # Important things to understand: 2204 # 2205 # 1. This feature is disabled by default, and only works if you compiled Redis 2206 # to use the copy of Jemalloc we ship with the source code of Redis. 2207 # This is the default with Linux builds. 2208 # 2209 # 2. You never need to enable this feature if you don't have fragmentation 2210 # issues. 2211 # 2212 # 3. Once you experience fragmentation, you can enable this feature when 2213 # needed with the command "CONFIG SET activedefrag yes". 2214 # 2215 # The configuration parameters are able to fine tune the behavior of the 2216 # defragmentation process. If you are not sure about what they mean it is 2217 # a good idea to leave the defaults untouched. 2218 2219 # Active defragmentation is disabled by default 2220 # activedefrag no 2221 2222 # Minimum amount of fragmentation waste to start active defrag 2223 # active-defrag-ignore-bytes 100mb 2224 2225 # Minimum percentage of fragmentation to start active defrag 2226 # active-defrag-threshold-lower 10 2227 2228 # Maximum percentage of fragmentation at which we use maximum effort 2229 # active-defrag-threshold-upper 100 2230 2231 # Minimal effort for defrag in CPU percentage, to be used when the lower 2232 # threshold is reached 2233 # active-defrag-cycle-min 1 2234 2235 # Maximal effort for defrag in CPU percentage, to be used when the upper 2236 # threshold is reached 2237 # active-defrag-cycle-max 25 2238 2239 # Maximum number of set/hash/zset/list fields that will be processed from 2240 # the main dictionary scan 2241 # active-defrag-max-scan-fields 1000 2242 2243 # Jemalloc background thread for purging will be enabled by default 2244 jemalloc-bg-thread yes 2245 2246 # It is possible to pin different threads and processes of Redis to specific 2247 # CPUs in your system, in order to maximize the performances of the server. 2248 # This is useful both in order to pin different Redis threads in different 2249 # CPUs, but also in order to make sure that multiple Redis instances running 2250 # in the same host will be pinned to different CPUs. 2251 # 2252 # Normally you can do this using the "taskset" command, however it is also 2253 # possible to this via Redis configuration directly, both in Linux and FreeBSD. 2254 # 2255 # You can pin the server/IO threads, bio threads, aof rewrite child process, and 2256 # the bgsave child process. The syntax to specify the cpu list is the same as 2257 # the taskset command: 2258 # 2259 # Set redis server/io threads to cpu affinity 0,2,4,6: 2260 # server_cpulist 0-7:2 2261 # 2262 # Set bio threads to cpu affinity 1,3: 2263 # bio_cpulist 1,3 2264 # 2265 # Set aof rewrite child process to cpu affinity 8,9,10,11: 2266 # aof_rewrite_cpulist 8-11 2267 # 2268 # Set bgsave child process to cpu affinity 1,10,11 2269 # bgsave_cpulist 1,10-11 2270 2271 # In some cases redis will emit warnings and even refuse to start if it detects 2272 # that the system is in bad state, it is possible to suppress these warnings 2273 # by setting the following config which takes a space delimited list of warnings 2274 # to suppress 2275 # 2276 # ignore-warnings ARM64-COW-BUG