プロセスが強制終了されるのを防ぐにはどうすればよいでしょうか?

プロセスが強制終了されるのを防ぐにはどうすればよいでしょうか?

プロセスが強制終了されるのを防ぐ方法はありますか? 知っていますが、nice長時間実行されるメモリを大量に消費するタスクにrake最高の優先度を与えることで、強制終了を防げるかどうかはわかりません。

nice -n -20 rake xyz

編集: 元の投稿者は、サーバーのリソースが不足していても、他のプロセスが最初に終了されるほど優先度を高くしたいと考えている可能性が高いです。

答え1

root がプロセスを強制終了するのを防ぐことはできません。また、サーバーがすべてのリソースを消費するプロセスを強制終了するのを防ぐこともできません。

実行できるのは、コマンドをフォークして、強制終了されたときにコマンドが自動的に再起動されるようにすることです。

コードの使用例:

答え2

さて、これは古い質問だとは思いますが、どちらの回答も明らかな点を無視しているか、せいぜい表面をなぞっているだけなので、自分で書いてみようと思いました。質問の文面からして、最初に頭に浮かんだのは「OOM キラー!」でした。他の回答の 1 つでは、「何かが自動的に強制終了されるわけではない」という主張さえありますが、これはユーザーの観点からはとんでもないことです。自動化でなければ、OOM キラーとは何でしょうか?

OOMキラーリンクされた記事が示すように、ここで説明したようなシナリオでは、が最大の敵となります。

正確なシナリオ(ビルドマシン、サーバーなど)によって異なりますが、一般的にはするOS がマシンのリソースを可能な限り活用できるようにしたいのです。それがそもそも私がこれらを購入した理由です。

あなたの質問の内訳:

プロセスが強制終了されるのを防ぐ方法はありますか?

いいえ、幸いなことにカーネルは不正な動作をするプロセスを強制終了する(例えばSIGSEGV)。これは、リソース制限に達したためにタスクが誤動作した場合にも適用されます(制限.conf制限を取得/制限を設定つまり、rakeタスク内の何か (おそらく他のプロセスを使用して何らかの作業を行う) が null ポインターを逆参照すると、運が悪くその部分が失敗し、その後タスクが失敗する可能性があります。

ルートはおそらく送信もできるだろう信号プロセスに組み込むことができます。どうにかユーザー空間に関連するものからプロセスを保護することができたrootとしても、カーネル モジュールをロードしてカーネルからのそれらの取り組みを弱体化させることは可能です (おそらくアクティブなカーネル ロックダウンを除く)。

nice長時間実行されるメモリを大量に消費するタスクにrake最高の優先度を与えることで、そのタスクが強制終了されるのを防げるかどうかはわかっていますが、よくわかりません。 [...]

防ぐことはできないが、意思使用される1つOOMキラーのいくつかのヒューリスティック。つまり、実際にnice意思少しだけ助けてください。LWN記事上記ですでにリンクした内容では、次のヒューリスティックが示されています。

  • タスクがゼロより大きいnice値スコアが2倍になる
  • スーパーユーザーまたは直接ハードウェアアクセスタスク (CAP_SYS_ADMIN、CAP_SYS_RESOURCE、または CAP_SYS_RAWIO) のスコアは 4 で割られます。これは累積的であり、つまり、ハードウェア アクセス権を持つスーパーユーザー タスクのスコアは 16 で割られます。
  • OOM状態が1つ発生した場合CPUセットチェックされたタスクがそのセットに属していない場合、そのスコアは 8 で割られます。
  • 結果のスコアは 2 の oom_adj 乗で乗算されます (つまり、正の場合、ポイント <<= oom_adj、それ以外の場合はポイント >>= -(oom_adj) になります)

値以外にもnice、これをルート(または指定された権限)で実行するか、 root、プロセスがOOMキラーによって強制終了されないようにすることができます(記事には全詳細) cgroup を作成します。

  1. mount -t cgroup -o oom oom /mnt/oom-killer
  2. mkdir /mnt/oom-killer/invincibles
  3. echo 0 > /mnt/oom-killer/invincibles/oom.priority
  4. echo <pid> > /mnt/oom-killer/invincibles/tasks<pid>rake タスクのプロセス ID はどこにありますか...

これで完了です。特定のプロセス グループを OOM キラーの攻撃から除外することができます。

しかし、この強引なやり方が初め最善の策です。まずは、oom_adj他のプロセスとの競争に勝ち抜くために、プロセスに手を加えることから始めるべきだと思います。特にこれがサーバーの場合、全体的にサービスサービスにとって重要ではない特定のタスクよりも重要な場合があります。したがって、注意して使用してください。さらに、メモリを大量に消費していないか監視する必要があります (sysstat などが役立ちます)。時系列データベースを使用してこれを実行し、グラフをプロットすると、メモリ リークに気付くこともあります。

それでもダメなら、ブレンダン・グレッグのウェブサイトそしてスタート測定するさまざまなパフォーマンス指標があります。また、彼の本を1冊手に入れることができるかどうかを確認してください。たとえば、タスク内のメモリ割り当てに関して、暴走のような状況が発生する可能性がありますrake長時間実行そしてメモリを大量に消費するしかし、これらは必ずしも関連しているわけではありません。BPF とその仲間によって、他の方法では得られない洞察を得ることができます。

答え3

なぜだろうそれは殺されるのでしょうか?

何かが自動的に殺されるわけではないからです。その質問に答え、なぜ何かが破壊対象として選択されるのかを説明すれば、解決策を思いつくかもしれません。

Rails のコマンドについて話しているということはrake、これはサーバー上で実行されているプロセスだと推測します。プロセスが強制終了されることを心配しているということは、リソースを使いすぎたためにサーバー ホストによって強制終了されていると考えられます。このような場合、強制終了されたプロセスを停止する方法はありません (また、あるべきでもありません)。

リソースを大量に消費するタスクがある場合は、リソースを追加購入してください。独自のサーバー時間を使用してください。または、ホストと契約して、ホストの費用でタスクを実行できるようにしてください。

関連情報