原因：寫數據到redis里面寫不進去，查看redis日志顯示：
Can't save in background: fork: Cannot allocate memory
在小內存的進程上做一個fork,不需要太多資源，但當這個進程的內存空間以Ｇ為單位時，fork就成為一件很恐怖的操作。
發現問題之后，我先通過sysctl -a查看linux內核參數vm.overcommit_memory（sysctl -a |grep "vm.overcommit_memory"）,我們直接修改內核參數為vm.overcommit_memory = 1
vm.overcommit_memory = 0：則比較 此次請求分配的虛擬內存大小和系統當前空閑的物理內存加上swap，決定是否放行。
vm.overcommit_memory = 1，直接放行。
vm.overcommit_memory = 2：則會比較 進程所有已分配的虛擬內存加上此次請求分配的虛擬內存和系統當前的空閑物理內存加上swap，決定是否放行。
修改方法：
編輯/etc/sysctl.conf添加vm.overcommit_memory = 1,運行systcl -p生效。
排查：
數據能寫入到redis里面了，但后面發現，這其實是治標不治本，數據還在增長，內存還是會被耗完。
查到根本原因是redis其中一個list數據是幾百萬級別，list的特點是取兩端數據塊，取中間數據慢，一般是做消息隊列或者熱數據分頁，存太多數據沒有意義。數據在寫入，讀數據的服務出了故障，出現僵屍進程。
解決：
實時監控各個服務，讀取redis數據的服務做一個集群，做負載均衡的同時也做高可用，從根本上解決這類型的問題。