問題のあるプロセスが強制終了されたにもかかわらず、メモリ不足のカーネル (3.2.0) パニック (Debian 7.3) が発生する

問題のあるプロセスが強制終了されたにもかかわらず、メモリ不足のカーネル (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

ディスク: ソフトウェア ミラー RAID モードの 1 TB ディスク 2 台、バックアップ専用の 2 TB ディスク 1 台。

疑念があります。サーバーのメモリは 2G RAM + 2G スワップ = 4G です。最大 16G のファイルがあります。rdiff-backupある時点でファイル全体がメモリにロードされる可能性はありますか?

いずれにせよ、カーネル パニックは発生しないはずです (rdiff プロセスが強制終了されたため、メモリが再び使用可能になっているはずです)。そのため、私の質問は 2 つの部分、つまり、1 つは私の疑いについて、もう 1 つはカーネル パニックについてであると思います。

ちなみに、パニックは最近発生し始めましたが、すでにかなりの数のバックアップ (完全バックアップと増分バックアップ) が成功しており、数 GB の大きなファイルもすでに存在していました。つまり、rdiff-backup ではなく、新しい Debian カーネルのせいなのでしょうか?

パニック発生時のログファイルセクションhttp://pastebin.com/e9a5fQdh

画面上の最後のもの:

編集/更新: 20GB のスワップ ファイル (/dev/zero からの dd を使用) を作成しようとしたところ、サーバーが再びダウンし、何も反応しなくなりましたping

ログを見ると、カーネルがいくつかのプロセスを強制終了したようです。その中には、すべての原因と思われるプロセス (rdiff-backup) も含まれています。しかし、「強制終了可能なプロセスが不足しています」と表示されます。プロセスを強制終了してもメモリが解放されなかったようです。

答え1

rdiff-backup は終了しませんでした。終了するはずでしたが、oom_score_adj-1000 です。

これは sshd のバグが原因です。バグは修正されましたが、次のリリースである openssh 6.5 までは利用できません。

sshd は、リロードすると、作成する新しいシェルの oom_score_adj を 0 に戻すことができないため、SSH 経由で生成するすべての子プロセス (つまり、bash シェルとそれが作成するすべての子プロセス) に -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

関連情報