735

私のアプリケーションは、Linux上でバックグラウンドプロセスとして実行されます。現在、ターミナルウィンドウのコマンドラインで起動しています。

最近、ユーザーがしばらくの間アプリケーションを実行していて、それが不思議なことに死にました。テキスト：

殺された

ターミナルにありました。これは2回起こりました。別のターミナルの誰かがkillコマンドを使用してプロセスを強制終了したかどうかを尋ねました。いいえ。

Linuxはどのような条件下で私のプロセスを強制終了することを決定しますか？kill（9）シグナルを受信した後にプロセスが停止したため、シェルは「killed」と表示されたと思います。Linuxがkillシグナルを送信した場合、システムログのどこかにkillされた理由を説明するメッセージがあるはずですか？

4

14 に答える 14

188

これは、このテーマに関する良い記事のように見えます：OOMキラーを飼いならす。

要点は、Linuxがオーバーコミットすることですメモリー。プロセスがより多くのスペースを要求すると、Linuxは、別のプロセスによって要求された場合でも、要求されたすべてのメモリを実際に使用する人がいないことを前提として、そのスペースを割り当てます。プロセスは、要求したときではなく、実際に使用したときに割り当てられたメモリを排他的に使用します。これにより、割り当てが迅速になり、実際よりも多くのメモリを「ごまかして」割り当てられる可能性があります。ただし、プロセスがこのメモリの使用を開始すると、Linuxは、持っていないメモリの割り当てが多すぎることに気付く可能性があり、一部を解放するためにプロセスを強制終了する必要があります。強制終了されるプロセスは、実行時間（長時間実行プロセスの方が安全）、メモリ使用量（貪欲なプロセスの方が安全性が低い）、およびその他のいくつかの要因を考慮したスコアに基づいています。プロセスが強制終了される可能性を低くするために調整できる値を含みます。それはすべて、記事でより詳細に説明されています。

編集：そして、これはプロセスがどのように選択されるかをかなりよく説明する別の記事です（いくつかのカーネルコード例で注釈が付けられています）。これの素晴らしいところは、さまざまなルールの背後にある理由についての解説が含まれていることです。badness()

于 2009-04-07T17:51:37.190 に答える
57

最初に、いつ、なぜ OOMKiller が呼び出されるのかを説明しましょう。

512 RAM + 1GB スワップ メモリがあるとします。したがって、理論的には、CPU は合計 1.5 GB の仮想メモリにアクセスできます。

現在、しばらくの間、すべてが 1.5GB の総メモリ内で正常に動作しています。しかし、システムが突然 (または徐々に) メモリを消費し始め、総メモリ使用量の約 95% に達しました。

ここで、任意のプロセスがカーネルに大量のメモリを要求したとします。カーネルが使用可能なメモリをチェックし、プロセスにそれ以上のメモリを割り当てる方法がないことを確認します。そのため、OOMKiller ( http://linux-mm.org/OOM ) を呼び出してメモリを解放しようとします。

OOMKiller には、すべてのプロセスのランクをスコアリングするための独自のアルゴリズムがあります。通常、より多くのメモリを使用するプロセスは、強制終了される犠牲者になります。

OOMKiller のログはどこにありますか?

通常、/var/log ディレクトリにあります。/var/log/kern.log または /var/log/dmesg のいずれか

これがあなたを助けることを願っています。

いくつかの典型的な解決策:

  1. メモリを増やす (スワップではない)
  2. プログラム内のメモリ リークを見つけて修正する
  3. すべてのプロセスが消費できるメモリを制限します (たとえば、JAVA_OPTS を使用して JVM メモリを制限できます)。
  4. ログとグーグルを参照してください:)
于 2016-04-05T00:36:36.813 に答える
14

dwc と Adam Jaskiewicz が述べているように、犯人はおそらく OOM キラーです。ただし、次の質問は次のとおりです。これを防ぐにはどうすればよいですか?

いくつかの方法があります:

  1. 可能であれば、システムに RAM を追加します (VM の場合は簡単です)。
  2. OOM キラーが別のプロセスを選択していることを確認してください。
  3. OOM キラーを無効にする
  4. OOM Killer が無効になっている Linux ディストリビューションを選択します。

この記事のおかげで、(2) は特に簡単に実装できることがわかりました。

于 2014-01-28T19:01:00.490 に答える
12

systemtap (またはトレーサー) のようなツールは、カーネルのシグナル送信ロジックを監視してレポートすることができます。例: https://sourceware.org/systemtap/examples/process/sigmon.stp

# stap --example sigmon.stp -x 31994 SIGKILL
   SPID     SNAME            RPID  RNAME            SIGNUM SIGNAME
   5609     bash             31994 find             9      SIGKILL

そのスクリプトのフィルタリングifブロックは好みに合わせて調整したり、システム全体の信号トラフィックをトレースするために削除したりできます。原因は、バックトレースを収集することでさらに分離できます (それぞれカーネル空間とユーザー空間のプローブにprint_backtrace()and/orを追加します)。print_ubacktrace()

于 2015-02-25T17:59:24.520 に答える
10

リソースを制限する PAM モジュールは、まさにあなたが説明した結果を引き起こしました。syslogにもkern.logにもログ出力はありません。topプログラムは、CPU 使用率がちょうど 1 分後にプロセスが強制終了されることを発見するのに役立ちました。

于 2012-04-26T19:20:17.763 に答える
4

lsf 環境 (インタラクティブまたはそれ以外) では、キューの管理者またはキューへの送信中のリソース要求によって、アプリケーションが事前に設定されたしきい値を超えてメモリ使用率を超えた場合、他のユーザーが潜在的な犠牲にならないようにプロセスが強制終了されます。逃げる。設定方法によっては、メールを送信するときに常にメールを送信するとは限りません。

この場合の 1 つの解決策は、より大きなリソースを持つキューを見つけるか、送信でより大きなリソース要件を定義することです。

レビューすることもできますman ulimit

ulimit私はそれが必要になってからしばらく経ったことを覚えていませんKilledが。

于 2012-03-03T07:07:59.570 に答える
2

Linuxでは顧客サイト（Red Hat、私は思う）で繰り返し問題が発生し、OOMKiller（メモリ不足キラー）が主要なアプリケーション（つまりサーバーが存在する理由）とそのデータベースプロセスの両方を強制終了しました。

いずれの場合も、OOMKillerは、プロセスが多くのリソースを使用していると単純に判断しました...リソースが不足しているためにマシンが故障することすらありませんでした。アプリケーションもそのデータベースも、メモリリーク（またはその他のリソースリーク）の問題はありません。

私はLinuxの専門家ではありませんが、何かをいつ殺すか、何を殺すかを決定するためのアルゴリズムを集めました。また、OOMKillerはカーネルに組み込まれているため、単純に実行できないと言われました（これの正確さについては言えません）。

于 2009-04-07T17:44:23.387 に答える
0

最近この問題に遭遇しました。最後に、Opensuse zypper update が自動的に呼び出された直後にプロセスが強制終了されていることがわかりました。zypper update を無効にすると、問題が解決しました。

于 2012-10-29T05:55:18.073 に答える
0

ユーザーは、kill または Control+C を使用して自分のプログラムを強制終了することができますが、実際にはそうではなく、ユーザーがあなたに不満を述べているように感じます。

もちろん、ルートにはプログラムを強制終了する機能がありますが、誰かがあなたのマシンにルートを持っていて、何かを強制終了している場合、より大きな問題が発生します。

あなたがシステム管理者でない場合、システム管理者が CPU、RAM、またはディスクの使用量にクォータを設定し、それらを超えるプロセスを自動強制終了している可能性があります。

これらの推測を​​除けば、プログラムに関する詳細情報がないとわかりません。

于 2009-04-07T17:12:54.803 に答える