Linux のメモリ不足のアプリケーションティアダウンを回避する

解決策 1:

デフォルトでは、Linux のメモリー管理の概念はいくぶん頭を悩ませています。つまり、システムが持っているよりも多くのメモリーを割り当てることができ、問題が発生したときにプロセスをランダムに終了させることができます。 (殺されるものの実際のセマンティクスはそれよりも複雑です - Google の「Linux OOM Killer」は、それが良いことか悪いことかについての多くの詳細と議論についてです)。

メモリ管理を正常に戻すには:

<オール>

OOM キラーを無効にする (Put vm.oom-kill = 0 /etc/sysctl.conf 内)

メモリのオーバーコミットを無効にする (Put vm.overcommit_memory = 2 /etc/sysctl.conf 内)
これは 3 値であることに注意してください:0 =「十分な RAM があるかどうかを見積もる」、1 =「常にはいと言います」、2 =「メモリがない場合はいいえと言います」)

これらの設定により、Linux は従来の方法で動作します (プロセスが利用可能なメモリよりも多くのメモリを要求した場合、malloc() は失敗し、メモリを要求するプロセスはその失敗に対処することが期待されます)。

マシンを再起動して /etc/sysctl.conf をリロードします、または proc を使用します再起動せずにすぐに有効にするファイルシステム:

echo 2 > /proc/sys/vm/overcommit_memory

解決策 2:

オーバーコミットを無効にすることができます。http://www.mjmwired.net/kernel/Documentation/sysctl/vm.txt#514 を参照してください

解決策 3:

サーバーの簡単な答えは、RAM を購入してインストールすることです。

定期的に OOM を経験したサーバー (Out-Of-Memory) エラー、Linux カーネルの VM (仮想メモリ) マネージャーの overcommit sysctl オプション以外では、これは良いことではありません。

スワップ (カーネルのメモリマネージャーによってディスクにページアウトされた仮想メモリ) の量を増やすと、現在の値が低く、1 つまたはいくつかではなく、大量のメモリごとに多くのタスクが使用されている場合に役立ちます。利用可能な合計仮想メモリ (RAM + スワップ) の膨大な量を要求する各プロセス。

スワップとして RAM の量を 2 倍以上 (2 倍) 割り当てる多くのアプリケーションでは、改善の効果が減少します。一部の大規模な計算シミュレーションでは、速度の低下が許容できる場合、これは許容される場合があります。

RAM（ECCかどうかに関係なく）を使用すると、適度な量で非常に手頃な価格になります。 4 ～ 16 GB、認めざるを得ませんが、私自身、この問題を長い間経験していません。

free の使用を含むメモリ消費量の基本および top 、メモリ使用パターンの 2 つの最も一般的な迅速な評価として、メモリ使用量で並べ替えます。そのため、少なくともこれらのコマンドの出力に含まれる各フィールドの意味を理解しておく必要があります。

アプリケーションの詳細 (データベース、ネットワークサービスサーバー、リアルタイムビデオ処理など) とサーバーの使用法 (少数のパワーユーザー、100 ～ 1000 のユーザー/クライアント接続) がないため、対処に関する一般的な推奨事項を思いつきません。 OOMの問題。

解決策 4:

ulimit を使用して、プロセスが強制終了される前にプロセスが要求できるメモリの量を減らすことができます。問題が、サーバーをクラッシュさせる 1 つまたはいくつかの暴走プロセスである場合に非常に役立ちます。

必要なサービスを実行するのに十分なメモリがないという問題がある場合、解決策は 3 つだけです:

<オール>

キャッシュなどを制限することで、サービスが使用するメモリを削減します

より大きなスワップ領域を作成します。パフォーマンスは低下しますが、時間は稼げます。

メモリを追加購入

解決策 5:

物理メモリの量を増やすことは、すべての状況で効果的な対応とは限りません。

これを確認する 1 つの方法は、'atop' コマンドです。特にこの 2 行。

これは正常だったときのサーバー外です:

MEM | tot   23.7G | free   10.0G | cache   3.9G | buff  185.4M | slab  207.8M |
SWP | tot    5.7G | free    5.7G |              | vmcom  28.1G | vmlim  27.0G |

パフォーマンスが悪いとき (overcommit_memory を 50 から 90 に調整する前は、vmcom が 50G をはるかに超えて実行され、oom-killer が数秒ごとにプロセスを爆破し、NFSd の子プロセスが爆破されたために負荷が急激に跳ね上がり続けた) という動作が見られました。継続的に作成および再作成されます。

最近、マルチユーザーの Linux ターミナルサーバーが仮想メモリの割り当てを大幅にオーバーコミットしているにもかかわらず、要求されたページのほとんどが実際に消費されていないというケースが再現されました。