redis近期踩的坑總結
阿新 • • 發佈:2018-12-25
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最高)。