redis近期踩的坑總結

1、主從問題

核心系統：公司之前開發自己部署的redis3主3從3哨兵，程式端分區，而且把哨兵部署到了主上。

剛好主掛了一台，導致整個系統可用。

最佳化部署：加一台虛擬機器作為哨兵專用機，共計9哨兵（3主3從9哨兵），經測試，可以正常切換。

2、帶上業務切換問題

前幾天剛好一台物理機掛了，哨兵正常切換，但是程式端報錯，發現串連redis池報錯，重啟web應用

程式後恢複。

最佳化程式：自動重連

網上找的，隔天讓開發的同學試試

http://www.mamicode.com/info-detail-1896700.html  

3、維修物理機

因為主都切換到別的機器上了，這台物理機上的虛擬機器全是備，感覺沒什麼問題，結果所有系統報卡

，看看web伺服器log，發現一直在找這掛掉的備機，也影響業務，看來我還是太單純了。還是應該在非

業務時間去做停機維護，無論是主還是備。

[ERROR]  2017-11-28 21:36:30.119 [Thread-8] [error_logger] - Lost connection to Sentinel at 192.168.2.99:36381. Sleeping 5000ms and retrying. [ERROR]  2017-11-28 21:36:30.134 [Thread-5] [error_logger] - Lost connection to Sentinel at 192.168.2.98:36380. Sleeping 5000ms and retrying.

[ERROR]  2017-11-28 21:36:30.241 [Thread-2] [error_logger] - Lost connection to Sentinel at 192.168.2.97:36379. Sleeping 5000ms and retrying.

4、因雙11活動，接著11月份做了很多活動redis裡緩衝的資料為到期，記憶體不夠用警示。

但是發現系統始終還有2g記憶體

兩個解決方案(overcommit_memory)1.  echo "vm.overcommit_memory=1" > /etc/sysctl.conf  或 vi /etcsysctl.conf , 然後reboot重啟機器2.  echo 1 > /proc/sys/vm/overcommit_memory  不需要啟機器就生效

overcommit_memory參數說明：設定記憶體配置策略（可選，根據伺服器的實際情況進行設定）/proc/sys/vm/overcommit_memory可選值：0、1、2。0， 表示核心將檢查是否有足夠的可用記憶體供應用進程使用；如果有足夠的可用記憶體，記憶體申請允許；否則，記憶體申請失敗，並把錯誤返回給應用進程。1， 表示核心允許分配所有的實體記憶體，而不管當前的記憶體狀態如何。2， 表示核心允許分配超過所有實體記憶體和交換空間總和的記憶體注意：redis在dump資料的時候，會fork出一個子進程，理論上child進程所佔用的記憶體和parent是一樣的，比如parent佔用 的記憶體為8G，這個時候也要同樣分配8G的記憶體給child,如果記憶體無法負擔，往往會造成redis伺服器的down機或者IO負載過高，效率下降。所 以這裡比較最佳化的記憶體配置策略應該設定為 1（表示核心允許分配所有的實體記憶體，而不管當前的記憶體狀態如何）。這裡又涉及到Overcommit和OOM。什麼是Overcommit和OOM在Unix中，當一個使用者進程使用malloc()函數申請記憶體時，假如傳回值是NULL，則這個進程知道當前沒有可用記憶體空間，就會做相應的處理工作。許多進程會列印錯誤資訊並退出。Linux使用另外一種處理方式，它對大部分申請記憶體的請求都回複"yes"，以便能跑更多更大的程式。因為申請記憶體後，並不會馬上使用記憶體。這種技術叫做Overcommit。當記憶體不足時，會發生OOM killer(OOM=out-of-memory)。它會選擇殺死一些進程(使用者態進程，不是核心線程)，以便釋放記憶體。Overcommit的策略Linux下overcommit有三種策略(Documentation/vm/overcommit-accounting)：0. 啟發學習法策略。合理的overcommit會被接受，不合理的overcommit會被拒絕。1. 任何overcommit都會被接受。2. 當系統分配的記憶體超過swap+N%*物理RAM(N%由vm.overcommit_ratio決定)時，會拒絕commit。overcommit的策略通過vm.overcommit_memory設定。overcommit的百分比由vm.overcommit_ratio設定。# echo 2 > /proc/sys/vm/overcommit_memory# echo 80 > /proc/sys/vm/overcommit_ratio當oom-killer發生時，linux會選擇殺死哪些進程選擇進程的函數是oom_badness函數(在mm/oom_kill.c中)，該函數會計算每個進程的點數(0~1000)。點數越高，這個進程越有可能被殺死。每個進程的點數跟oom_score_adj有關，而且oom_score_adj可以被設定(-1000最低，1000最高)。