記憶體不足的核心（3.2.0）恐慌（Debian 7.3）即使有問題的程序被殺死

嘗試將相當大的文件夾 (450G) 備份到該伺服器中僅作為備份目標的 2TB 驅動器時rdiff-backup（版本 1.2.8 - 最後標記為stable）導致核心恐慌。

系統：

Linux giorgio 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux

磁碟：軟體鏡像 RAID 模式下 2 個 1TB 磁碟，1 個 2TB 磁碟僅用於備份。

我有一個懷疑：伺服器上的記憶體是 2G RAM + 2G swap = 4G。文件最大為 16G。是否有可能rdiff-backup在某些時候將整個文件載入到記憶體中？

無論如何，不應該發生核心恐慌（因為 rdiff 程序被殺死了？所以記憶體應該再次可用？），所以我想我的問題有兩個部分，一：關於我的懷疑，二：關於核心恐慌。

順便說一句，恐慌最近開始了，相當多的備份已經成功 - 完整的和增量的 - 並且那些大 GB 文件已經存在。所以我猜這是新的 Debian 核心的錯，而不是 rdiff-backup 的錯？

發生恐慌時的日誌文件部分http://pastebin.com/e9a5fQdh

螢幕上的最後一件事：

編輯/更新：我剛剛嘗試創建一個 20GB 交換文件（使用 /dev/zero 中的 dd），伺服器再次關閉，對ping.

從查看日誌來看：似乎核心已經殺死了一些程序——包括我懷疑導致這一切的程序（rdiff-backup）——但是說“用完了可殺死的程序”。似乎殺死程序並沒有釋放記憶體？

它沒有殺死 rdiff-backup，它應該有，但它oom_score_adj是 -1000。

這是由 sshd 中的錯誤引起的。該錯誤已修復，但直到下一個版本是 openssh 6.5 才可用。

如果重新載入，sshd 無法將它創建的新 shell 的 oom_score_adj 設置回 0，從而導致您通過 SSH 生成的所有子程序（因此您的 bash shell 和創建的任何子程序）具有 -1000oom_score_adj並隨後可以佔用所有記憶體沒有 oom-killer 殺死他們。

解決此問題的最快方法是（假設 7567 是 sshd 的 pid，就像您的情況一樣）：-

• 跑echo 0 >/proc/7567/oom_adj_score
• 重啟sshd。

不要重新載入 sshd，重新啟動它直到修復到位。（openssh 6.5 應該有）

該錯誤在此處報告並修復。https://bugzilla.mindrot.org/show_bug.cgi?id=2156

引用自：https://serverfault.com/questions/563762