解決策 1:
メモリのオーバーコミットは vm.overcommit_memory=2 で無効にできます
0 はデフォルトのモードで、カーネルは作成された割り当て要求と比較して空きメモリを計算することにより、割り当てをヒューリスティックに決定します。また、1 に設定するとウィザードモードが有効になり、カーネルは割り当てに十分な空きメモリがあることを常にアドバタイズします。 2 に設定すると、プロセスは構成可能な量 (overcommit_ratio) までしか割り当てられないことを意味します。 ) の RAM であり、その量を超えると、割り当ての失敗または OOM メッセージを受け取り始めます。
そうしても安全ですか、いいえ。ワークロードとハードウェアの容量が 100% 確実でない限り、メモリのオーバーコミットを無効にすることが実際に役立つ適切な使用例は見たことがありません。興味のある方は kernel-docs をインストールしてください パッケージして /Documentation/sysctl/vm.txt に移動します 詳細を読むか、オンラインで読んでください。
vm.overcommit_memory=2 を設定した場合 次に、vm.overcommit_ratio で構成された物理 RAM のパーセンテージまでオーバーコミットします。 (デフォルトは 50% です)。
echo 0/1/2 > /proc/sys/vm/overcommit_memory
これは、再起動後は存続しません。永続性のために、これを /etc/sysctl.conf に入れます ファイル:
vm.overcommit_memory=X
sysctl -p を実行します .再起動する必要はありません。
解決策 2:
完全に無条件のステートメント:メモリのオーバーコミットを無効にすることは、有効にするよりも確実に「安全」です。
$customer はそれを数百の Web サーバーに設定し、安定性の問題を大幅に改善しました。Nagios のチェックで、無効にされていない場合でも、非常に大きな声で発砲することさえあります.
一方、小さなRAMをオーバーコミットしたいだけで、実際にはそれを使用しない場合、プロセスがメモリ不足になることは「安全」であるとは考えないかもしれません.(つまり、SAPは非常に良い例です)
それで、あなたはそれがあなたのために物事を改善するかどうかを見ることに戻ります.あなたはすでに関連する問題を取り除くためにそれを調べているので-私はそれがあなたのために役立つと思います.
(不機嫌そうな人に反対票を投じられるリスクがあることは承知しています)
解決策 3:
状況によっては、オーバーコミットを有効にするよりも無効にする方が安全であることに同意します。サーバーが少数の大容量メモリ ジョブ (私の場合は回路シミュレーションなど) しか実行しない場合は、OOM イベント (確実にすぐ後に続く) を待つよりも、事前にアプリケーションのメモリ要求を拒否する方がはるかに安全です。 OOM キラーが作業を完了した後に問題が発生します。