☰

即使有問題的進程被終止，記憶體不足的核心 (3.2.0) 恐慌 (Debian 7.3)

tag-icon • tag-icon linux debian kernel-panic rdiff-backup outofmemoryerror
即使有問題的進程被終止，記憶體不足的核心 (3.2.0) 恐慌 (Debian 7.3)

嘗試將相當大的資料夾 (450G) 備份到該伺服器中的 2TB 磁碟機時，該磁碟機僅作為備份目標rdiff-backup（版本 1.2.8 - 最後標記為穩定的）導致內核恐慌。

系統：

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

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

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

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

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

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

螢幕上的最後一件事：

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

從查看日誌來看：似乎內核已經殺死了一些進程 - 包括我懷疑導致這一切的進程（rdiff-backup） -但說「耗盡了可殺死的進程」。好像殺死進程並沒有釋放記憶體？

答案1

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

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

如果重新加載，sshd 無法將它創建的新 shell 的 oom_score_adj 設定回 0，導致透過 SSH 產生的所有子進程（因此您的 bash shell 和創建的任何子進程）的值為 -1000 oom_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

相關內容