Shulou(Shulou.com)06/03 Report--

Today, the developer suddenly told me that redis could not be written. When I entered the redis, I found that this was indeed the case. I could not execute the set instruction. The error is as follows:

172.31.18.90 set test test1 6379 >

(error) MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error.

Redis has always been normal before. It's not a permission problem, and it's not running out of memory.

By looking at log, we found that this is the error report fork: Cannot allocate memory

Making a fork on a process with small memory does not require much resources, but when the memory space of the process is in G units, fork becomes a very scary operation. What about fork 14-gigabyte processes on hosts with 16 GB of memory? It will be reported that the memory cannot be allocated. What is more exasperating is that the more frequently the fork is changed on the host, the cost of the fork operation itself may not be much better than that of fake death.

After finding the reason, modify the kernel parameter vm.overcommit_memory = 1 directly

Sysctl-p enables kernel parameters to take effect

Parameter explanation:

The Linux kernel decides whether to release or not based on the setting of the parameter vm.overcommit_memory parameter.

If vm.overcommit_memory = 1, release it directly.

Vm.overcommit_memory = 0: compare the virtual memory allocated for this request with the current free physical memory of the system plus swap to decide whether to release it.

Vm.overcommit_memory = 2: all the virtual memory allocated by the process plus the virtual memory allocated by this request is compared with the system's current free physical memory plus swap to decide whether to release it.

Here is to re-send the write-back mechanism of redis.

There are two kinds of data write-back mechanisms in Redis: synchronous and asynchronous.

Synchronous writeback is the SAVE command, and the main process writes back data directly to the disk. In the case of large data, it will cause the system to fake death for a long time, so it is generally not recommended.

Asynchronous writeback is the BGSAVE command. After the main process fork, it copies itself and writes back to the disk through this new process. After the writeback ends, the new process shuts down itself. Since this does not require blocking of the main process, the system will not fake death, and this method is generally used by default.

Note here:

Running the config set stop-writes-on-bgsave-error no command in redis can only temporarily solve the problem of not set. If something goes wrong, you still have to see log.

Default configuration stop-writes-on-bgsave-error yes data cannot be modified when an bgsave error occurs

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.