起因
最近用于做日志消息隊列的redis，突然掛了，也不能說是掛了，但是就是redis不起作用了，寫入無法寫入，讀取無法讀取，但是redis還是運行著的。就像突然罷工一樣。打開日志：
當(dāng)時登錄redis所在的服務(wù)器，發(fā)現(xiàn)redis占用的內(nèi)存已經(jīng)有5個G了，就這樣僵住了。后面我嘗試重啟redis，redis打出的日志是：
然后redis就卡在這卡住了，我觀察日志，發(fā)現(xiàn)redis提示vm的一個參數(shù)overcommit_memory現(xiàn)在的值是0，需要設(shè)置成1。
后面上網(wǎng)查詢資料得：
參數(shù)overcommit_memory的三種取值：
0 – Heuristic overcommit handling. 缺省值，它允許overcommit，但過于明目張膽的overcommit會被拒絕，比如malloc一次性申請的內(nèi)存大小就超過了系統(tǒng)總內(nèi)存。Heuristic的意思是“試探式的”，內(nèi)核利用某種算法猜測你的內(nèi)存申請是否合理，它認為不合理就會拒絕overcommit。
1 – Always overcommit. 允許overcommit，對內(nèi)存申請來者不拒。
2 – Don’t overcommit. 禁止overcommit。
如果設(shè)置為0，申請的內(nèi)存無法滿足時（根據(jù)內(nèi)部算法），則會觸發(fā)OOM。
如果設(shè)置為1，申請的內(nèi)存無法滿足時（根據(jù)內(nèi)部算法），部分會觸發(fā)OOM，部分觸發(fā)重啟。
如果設(shè)置為2，申請的內(nèi)存無法滿足時，則禁止分配。那閾值是多少，由內(nèi)部算法決定。它是通過內(nèi)核參數(shù)vm.overcommit_ratio或vm.overcommit_kbytes間接設(shè)置的，公式如下：
【CommitLimit = (Physical RAM * vm.overcommit_ratio / 100) + Swap】
overcommit_ratio默認為50，如有特殊需求，可以自己修改。
解決
1.修改參數(shù)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的消息積壓
后面我了解到，公司內(nèi)部接入到我自己部署的這套分布式日志系統(tǒng)的系統(tǒng)太多，導(dǎo)致日志產(chǎn)生的速度太快，而我在plumelog服務(wù)端配置的消費日志消息是每秒鐘消費2000條，這個消費的速度明顯太慢，最后為了避免redis的消費積壓，我將plumelog服務(wù)端配置的消費日志消息是每秒鐘消費10000條，然后觀察中發(fā)現(xiàn)，redis的內(nèi)存慢慢降下來了，整個分布式日志服務(wù)系統(tǒng)又恢復(fù)了。
