原因：写数据到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数据的服务做一个集群，做负载均衡的同时也做高可用，从根本上解决这类型的问题。