啓動錯誤
1.WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
2.WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
解決方法
第一個警告兩個方式解決(overcommit_memory)
1. echo "vm.overcommit_memory=1" > /etc/sysctl.conf 或 vi /etcsysctl.conf , 然後reboot重啓機器
2. echo 1 > /proc/sys/vm/overcommit_memory 不需要啓機器就生效
第二個警告解決
1. echo 511 > /proc/sys/net/core/somaxconn
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最高)。
在linux中，/proc/sys/net/core/somaxconn這個參數，linux中內核的一個不錯的參數somaxconn
對於一個TCP連接，Server與Client需要通過三次握手來建立網絡連接.當三次握手成功後,
我們可以看到端口的狀態由LISTEN轉變爲ESTABLISHED,接着這條鏈路上就可以開始傳送數據了.
每一個處於監聽(Listen)狀態的端口,都有自己的監聽隊列.監聽隊列的長度,與如下兩方面有關:
- somaxconn參數.
- 使用該端口的程序中listen()函數.
1. 關於somaxconn參數:
定義了系統中每一個端口最大的監聽隊列的長度,這是個全局的參數,默認值爲128,具體信息爲:
Purpose:
Specifies the maximum listen backlog.
Values:
Default: 128 connections
Range: 0 to MAXSHORT
Type: Connect
Diagnosis:
N/A
Tuning
Increase this parameter on busy Web servers to handle peak connection rates.
看下FREEBSD的解析：
限制了接收新 TCP 連接偵聽隊列的大小。對於一個經常處理新連接的高負載 web服務環境來說，默認的 128 太小了。大多數環境這個值建議增加到 1024 或者更多
參考：