共计 1121 个字符，预计需要花费 3 分钟才能阅读完成。
今天开发突然和我说 Redis 不能写了。我进入 Redis 后发现确实是这样，不可以执行 set 指令了。报错如下：
172.31.18.90:6379> set test test1
(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 一直是正常的。不是权限问题导致的，也不是内存耗尽通过查看 log 发现是这个报错 fork: Cannot allocate memory
在小内存的进程上做一个 fork, 不需要太多资源，但当这个进程的内存空间以G为单位时，fork 就成为一件很恐怖的操作。何况在 16G 内存的主机上 fork 14G 内存的进程呢？肯定会报内存无法分配的。更可气的是，越是改动频繁的主机上 fork 也越频繁，fork 操作本身的代价恐怕也不会比假死好多少。找到原因之后，直接修改内核参数 vm.overcommit_memory = 1,sysctl -p 使内核参数生效.
Linux 内核会根据参数 vm.overcommit_memory 参数的设置决定是否放行。
如果 vm.overcommit_memory = 1，直接放行 vm.overcommit_memory = 0：则比较 此次请求分配的虚拟内存大小和系统当前空闲的物理内存加上 swap，决定是否放行。vm.overcommit_memory = 2：则会比较 进程所有已分配的虚拟内存加上此次请求分配的虚拟内存和系统当前的空闲物理内存加上 swap，决定是否放行。
这里在重新发一下 redis 的回写机制,Redis 的数据回写机制分同步和异步两种，同步回写即 SAVE 命令，主进程直接向磁盘回写数据。在数据大的情况下会导致系统假死很长时间，所以一般不是推荐的。异步回写即 BGSAVE 命令，主进程 fork 后，复制自身并通过这个新的进程回写磁盘，回写结束后新进程自行关闭。由于这样做不需要主进程阻塞，系统不会假死，一般默认会采用这个方法。
在 redis 中运行 config set stop-writes-on-bgsave-error no 命令只能暂时解决不能 set 的问题。出了问题还是要看 log 的默认配置 stop-writes-on-bgsave-error yes 当 bgsave 出错时数据将不能修改。
