配置 vm.overcommit_memory 的效果
我在 CentOS 5.4（Linux 核心 2.6.16.33-xenU）上執行的 VPS 網路伺服器由於 oom-killer 啟動而不定期（例如每月一次或需要幾週）變得無響應。對伺服器的監控表明它沒有通常記憶體不足，只是每隔一段時間。
我已經閱讀了一些指向此頁面的部落格，其中討論了使用以下 sysctl 設置配置核心以更好地管理過度使用：
vm.overcommit_memory = 2 vm.overcommit_ratio = 80我對此的理解（這可能是錯誤的，但我找不到規範的定義來澄清）是這樣可以防止核心過度分配記憶體超出交換 + 80% 的物理記憶體。
但是，我也閱讀了其他一些資料，暗示這些設置不是一個好主意——儘管這種方法的批評者似乎在說“不要做任何事情來破壞你的系統，而不是嘗試這種混搭”，假設是因果總是已知的。
所以我的問題是，在託管大約 10 個低流量站點的 Apache2 Web 伺服器的上下文中**，這種方法的優缺點是什麼？**在我的具體情況下，Web 伺服器有 512Mb RAM，1024Mb 交換空間。這對於絕大多數時間來說似乎已經足夠了。
設置
overcommit_ratio為 80 可能不是正確的操作。將該值設置為小於 100 的值幾乎總是不正確的。這樣做的原因是 linux 應用程序分配的比他們真正需要的要多。假設他們分配 8kb 來儲存幾個字元串的文本。好吧，那裡有幾個 KB 未使用。應用程序經常這樣做，這就是過度使用的設計目的。
所以基本上過量使用為 100 時，核心將不允許應用程序分配比您擁有的更多的記憶體（交換 + 記憶體）。將其設置為小於 100 意味著您永遠不會使用所有記憶體。如果要設置此設置，則應將其設置為高於 100，因為上述情況很常見。
但是，雖然將其設置為大於 100 幾乎總是正確的答案，但在某些案例中，將其設置為小於 100 是正確的。如前所述，這樣做您將無法使用所有記憶體。但是核心仍然可以。所以你可以有效地使用它來為核心保留一些記憶體（例如頁面記憶體）。
現在，至於您觸發 OOM 殺手的問題，手動設置過度使用不太可能解決此問題。預設設置（啟發式確定）相當智能。
如果您想查看這是否真的是問題的原因，請查看
/proc/meminfoOOM 殺手何時執行。如果您看到Committed_AS接近CommitLimit，但free仍顯示可用記憶體，那麼是的，您可以為您的場景手動調整過度使用。將此值設置得太低將導致 OOM 殺手在您仍有大量可用記憶體時開始殺死應用程序。將其設置得太高可能會導致隨機應用程序在嘗試使用分配的記憶體時死掉，但實際上並不可用（當所有記憶體都實際用完時）。