起因

最近用于做日志消息队列的redis，突然挂了，也不能说是挂了，但是就是redis不起作用了，写入无法写入，读取无法读取，但是redis还是运行着的。就像突然罢工一样。打开日志：

image.png

当时登录redis所在的服务器，发现redis占用的内存已经有5个G了，就这样僵住了。后面我尝试重启redis，redis打出的日志是：

image.png
然后redis就卡在这卡住了，我观察日志，发现redis提示vm的一个参数overcommit_memory现在的值是0，需要设置成1。
后面上网查询资料得：

参数overcommit_memory的三种取值：
0 – Heuristic overcommit handling. 缺省值，它允许overcommit，但过于明目张胆的overcommit会被拒绝，比如malloc一次性申请的内存大小就超过了系统总内存。Heuristic的意思是“试探式的”，内核利用某种算法猜测你的内存申请是否合理，它认为不合理就会拒绝overcommit。
1 – Always overcommit. 允许overcommit，对内存申请来者不拒。
2 – Don’t overcommit. 禁止overcommit。

如果设置为0，申请的内存无法满足时（根据内部算法），则会触发OOM。
如果设置为1，申请的内存无法满足时（根据内部算法），部分会触发OOM，部分触发重启。
如果设置为2，申请的内存无法满足时，则禁止分配。那阈值是多少，由内部算法决定。它是通过内核参数vm.overcommit_ratio或vm.overcommit_kbytes间接设置的，公式如下：
【CommitLimit = (Physical RAM * vm.overcommit_ratio / 100) + Swap】
overcommit_ratio默认为50，如有特殊需求，可以自己修改。

解决

1.修改参数overcommit_memory方法：

1、编辑/etc/sysctl.conf ，改vm.overcommit_memory=1，然后sysctl -p 使配置文件生效
2、sysctl vm.overcommit_memory=1
3、echo 1 > /proc/sys/vm/overcommit_memory

2.增加redis的消息消费，尽量避免redis的消息积压

后面我了解到，公司内部接入到我自己部署的这套分布式日志系统的系统太多，导致日志产生的速度太快，而我在plumelog服务端配置的消费日志消息是每秒钟消费2000条，这个消费的速度明显太慢，最后为了避免redis的消费积压，我将plumelog服务端配置的消费日志消息是每秒钟消费10000条，然后观察中发现，redis的内存慢慢降下来了，整个分布式日志服务系统又恢复了。