banner
李大仁博客

李大仁博客

天地虽大,但有一念向善,心存良知,虽凡夫俗子,皆可为圣贤。

[Redis] Solving the "Cannot save in background" issue during Redis runtime.

[Redis] Resolving the "Cannot save in background" issue during Redis runtime

Redis is an open-source, log-based, key-value database that is written in ANSI C language and supports networking. It can be used in-memory or with persistence and provides APIs in multiple languages. Starting from March 15, 2010, Redis development has been led by VMware. Since May 2013, Redis development has been sponsored by Pivotal.

During Redis runtime, the "Cannot save in background" issue often occurs. This is usually due to two reasons. Firstly, if Redis consumes too much memory, the BGSAVE process may fail because the system cannot allocate enough memory to it. In such cases, you can limit the maximum memory size of Redis to be within half of the system memory. You can modify the maxmemory property in the redis.conf file.

maxmemory # Set it to be within half of the actual installed memory, for experimental environments, it is recommended not to exceed 1/3.

If your machine has limited memory but fast disk speed (SSD level), you can enable Redis's VM feature. Otherwise, it is recommended to disable the VM feature directly. In experimental environments, you can directly disable VM.

vm-enable no # Disable VM

Secondly, if the time interval between two BGSAVE triggers is too short, the BGSAVE operation queue may be blocked, resulting in an error. In such cases, you can adjust the BGSAVE trigger strategy of Redis based on your program's situation. Find the save configurations in the redis.conf file and make the corresponding adjustments according to your requirements. Configure the strategy according to your actual production environment. The goal is to minimize the number of BGSAVE operations.

save 1000 1 # Perform save if there is 1 update within 1000 seconds (low frequency)
save 250 10 # Perform save if there are 10 updates within 250 seconds (medium frequency)
save 120 1000 # Perform save if there are 1000 updates within 120 seconds (high frequency)
save 40 10000 # Perform save if there are 10000 updates within 40 seconds (ultra-high frequency, not necessary for experimental environments)

The first parameter represents the time interval in seconds, and the second parameter represents the number of updates.

Finally, enabling the write compression attribute can effectively reduce the disk writing time for each BGSAVE operation.

rdbcompression yes

Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.