交換可能なサービスのためにsystemdでOOMScoreAdjust = 1000を設定することをお勧めしますか？
systemdにはOOMScoreAdjustオプションがあり、開始されたプロセスのoom-killerスコアを調整できます。
systemdドキュメント から引用するには：
OOMScoreAdjust=実行されたプロセスのメモリ不足キラーの調整レベルを設定します。 -1000（このプロセスのOOM強制終了を無効にするため）から1000（メモリ不足によるこのプロセスの強制終了を可能にするため）の間の整数を取ります。詳細は proc.txt を参照してください。
私のセットアップでは、AWSにNodeJsサーバーをデプロイしています。 Nodeサーバーのほかに、EC2インスタンスで他に実行されているものはほとんどありません（監視と重要なOSプロセスを予期します）。ELBヘルスチェックが実施されており、最終的に壊れたEC2インスタンスを置き換えます。
それでも、OOMScoreAdjustを増やして、カーネルにNodeサーバープロセスを強制的に強制終了させることは、メモリの問題がある場合は自動的に再起動できるためです。 systemdでは、次のようになります。
OOMScoreAdjust=1000
Restart=always
私の理解は限られていることを認めざるを得ません。私の現在の理解では、それは実際には違いを生まない可能性が高く、デフォルトをそのままにしておく方がよいということです。
- メモリドレインプロセスがNodeサーバーの場合、とにかく強制終了されます。
- 原因が別のプロセスである場合は、Nodeサーバーを再起動しても効果がなく、ELBヘルスチェックによってインスタンスの置き換えが最終的に処理されます。
それでも、より良い理解を持つ誰かがすでにそれを熟考しているかどうか、私は興味があります。これを有効にするのは、systemdスクリプトでは1行だけです。疑わしいときは、ランダムなシステムサービスよりも、Nodeプロセスをカーネルに強制終了させます。
単一のプロセスを持つサーバーの場合、おそらく大きな違いはありませんが、メモリを頻繁にリークするプロセスがある場合、これは本当に効果的です。
たとえばデスクトップでは、FirefoxはOOM-killerが呼び出されるまでメモリをますます使用する傾向があり、常にXorgが最も多くのメモリを使用していると判断し、それを強制終了して、本当にブラウザのみであったときにデスクトップ全体をダウンさせます再起動する必要がありました。
したがって、この場合、リーキープログラムにOOMスコア1000を設定し、すぐに再起動するように設定しても問題はありません。最初に強制終了され、リロードすると以前ほど多くのメモリを使用しないため、解放されます。メモリ全体。
プロセスがかなり一定のメモリを使用している場合、問題になる可能性は低いですが（確かに害はありません）、リークがある場合は、AWS ELBが問題を認識して新しいVMを構築するよりも早く回復する可能性があります。