web-dev-qa-db-ja.com

問題のあるプロセスが強制終了されたにもかかわらず、メモリ不足のカーネル（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スワップ= 4Gです。最大16Gのサイズのファイルがあります。rdiff-backupある時点で、ファイル全体をメモリにロードしますか？

いずれにせよ、カーネルパニックは発生しないはずだったので（rdiffプロセスが強制終了されたので、メモリが再び利用可能になるはずでしたか？）、私の質問には2つの部分があります。1つは疑惑について、2つは疑惑についてです。カーネルパニック。

ちなみに、最近パニックが始まり、かなりの数のバックアップがすでに成功しており（完全および増分）、それらの大きなGBファイルはすでに存在していました。だから私はそれがrdiff-backupのせいではなく新しいDebianカーネルのせいだと思いますか？

パニックが発生したときのログファイルセクション http://Pastebin.com/e9a5fQdh

画面の最後のもの： 

編集/更新：20GBのスワップファイル（/ dev/zeroからのddを使用）を作成しようとしましたが、サーバーが再びダウンし、pingに反応しませんでした。

ログを見ると、カーネルがいくつかのプロセスを強制終了したようです-すべてを引き起こしたと思われるプロセス（rdiff-backup）を含む-が、「強制終了可能なプロセスが不足しています」と表示されます。プロセスを強制終了してもメモリは解放されなかったようです？

linuxdebiankernel-panicrdiff-backupoutofmemoryerror
3
Mörre

Rdiff-backupを強制終了しませんでした。強制終了する必要がありますが、oom_score_adjは-1000です。

これは、sshdのバグが原因です。バグは修正されていますが、openssh6.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

5
Matthew Ife