檢視 Redis 日誌
發現系統在頻繁報錯：
[1821] 10 Nov 09:59:04.086 # Can`t save in background: fork: Cannot allocate memory
[1821] 10 Nov 09:59:10.002 * 1 changes in 900 seconds. Saving...
在小記憶體的程式上做一個fork,不需要太多資源，但當這個程式的記憶體空間以Ｇ為單位時，fork就成為一件很恐怖的操作。何況在16G記憶體的主機上fork 14G記憶體的程式呢？肯定會報記憶體無法分配的。更可氣的是，越是改動頻繁的主機上fork也越頻繁，fork操作本身的代價恐怕也不會比假死好多少。
找到原因之後，直接修改核心引數 vm.overcommit_memory = 1
Linux核心會根據引數vm.overcommit_memory引數的設定決定是否放行。
如果 vm.overcommit_memory = 1，直接放行
vm.overcommit_memory = 0：則比較 此次請求分配的虛擬記憶體大小和系統當前空閒的實體記憶體加上swap，決定是否放行。
vm.overcommit_memory = 2：則會比較 程式所有已分配的虛擬記憶體加上此次請求分配的虛擬記憶體和系統當前的空閒實體記憶體加上swap，決定是否放行。
linux設定vm.overcommit_memory 方法
永久性修改核心引數
在/etc/sysctl.conf檔案裡面加入或者直接刪除也可以，因為它預設值就是0
vm.overcommit_memory = 0
執行使之生效
#sysctl -p