Linuxのメモリ不足アプリケーションの分解を避ける

Linuxボックスがメモリ不足になり、ランダムなプロセスを取り壊して対処することがあることがわかりました。

これを避けるために管理者が何をするのか興味がありますか？メモリの量を増やす唯一の本当の解決策は（スワップだけを増やすのに役立つでしょうか？）、またはこれを回避するためにソフトウェアでボックスをセットアップするより良い方法がありますか？（つまり、クォータ、またはそのようなもの？）。

デフォルトでは、Linuxのメモリ管理の概念は脳にややダメージを与えています。システムに搭載されているよりも多くのメモリを割り当て、問題が発生したときにランダムにプロセスをランダムに実行できます。（殺されるものの実際のセマンティクスは、それよりも複雑です-Googleの「Linux OOM Killer」は、それが良いことなのか悪いことなのかについての多くの詳細と議論を示しています）。

メモリ管理の健全性を復元するには：

1. OOMキラーを無効にする（Put vm.oom-kill = 0 /etc/sysctl.confに追加）
2. メモリのオーバーコミットを無効にします（vm.overcommit_memory = 2/etc/sysctl.confに入力します）
   これは3進値であることに注意してください。メモリを持っている」）

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

マシンをリブートしてリロード/etc/sysctl.confするか、procファイルシステムを使用して、リブートせずにすぐに有効にします。

echo 2 > /proc/sys/vm/overcommit_memory 

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

サーバーに対する短い答えは、RAMを追加購入することです。

定期的にOOM（Out-Of-Memory）エラーが発生したサーバーは、LinuxカーネルでVM（仮想メモリ）マネージャーのオーバーコミットsysctlオプションを除いて、これは良いことではありません。

スワップ（カーネルのメモリマネージャによってディスクにページアウトされた仮想メモリ）の量を増やすと、現在の値が低く、使用量が1つまたは少数ではなく、そのような大量のメモリの多くのタスクを伴う場合に役立ちます使用可能な仮想メモリ全体（RAM +スワップ）の膨大な量を要求するそれぞれを処理します。

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

RAM（ECCであるかどうかに関係なく）は、4〜16 GBなどの適度な量でかなり手頃な価格です。私は長い間、この問題を経験していません。

メモリ使用パターンの基本的な2つの最も一般的な迅速な評価として、メモリ使用量でソートされた、を使用するfreeなどtop、メモリ消費量を調べる際の基本事項。したがって、少なくともこれらのコマンドの出力の各フィールドの意味を理解してください。

アプリケーション（データベース、ネットワークサービスサーバー、リアルタイムビデオ処理など）の仕様やサーバーの使用状況（パワーユーザーが少ない、100〜1000のユーザー/クライアント接続）がないため、処理に関する一般的な推奨事項は考えられません。 OOMの問題。

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

これを確認する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をはるかに超えて動作し、数秒ごとにプロセスを爆破し、NFSd子プロセスが爆破するために負荷が急激にバウンスし続ける）動作が見られました継続的に再作成されます。

最近、マルチユーザーLinuxターミナルサーバーが仮想メモリの割り当てを過度にオーバーコミットしているのに、要求されたページのほとんどが実際に消費されていないケースを複製しました。

この正確なルートに従うことはお勧めできませんが、オーバーコミットメモリをデフォルトの50から90に調整して、問題の一部を軽減しました。すべてのユーザーを別のターミナルサーバーに移動し、再起動して完全な利点を確認する必要がありました。

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

問題が、必要なサービスを実行するのに十分なメモリがないことだけである場合、3つの解決策しかありません。

1. キャッシュなどを制限することにより、サービスで使用されるメモリを削減します

2. より大きなスワップ領域を作成します。パフォーマンスにコストがかかりますが、ある程度の時間を費やすことができます。

3. メモリを追加購入する

このバグに関連した同様の問題があり、解決策は古い/新しい（修正済み）カーネルを使用することでした。

ただし、その時点でマシンを再起動できなかったため、何らかの厄介な回避策は、rootとしてログインし、次のコマンドでシステムキャッシュをクリアすることでした。

echo 3 > /proc/sys/vm/drop_caches

@ voretaq7 linuxには、脳にダメージを与えるメモリ管理の概念がありません。デフォルトでは、vm.overcommit_ratioは0です。

0       -   Heuristic overcommit handling. Obvious overcommits of
            address space are refused. Used for a typical system. It
            ensures a seriously wild allocation fails while allowing
            overcommit to reduce swap usage.  root is allowed to
            allocate slightly more memory in this mode. This is the
            default.

このように、4GBのRAMがあり、仮想メモリのmallocで4.2GBを割り当てようとすると、割り当ては失敗します。

vm.overcommit_ratio = 1の場合

            1    -   Always overcommit. Appropriate for some scientific
            applications. Classic example is code using sparse arrays
            and just relying on the virtual memory consisting almost
            entirely of zero pages.

vm.overcommit_ratio = 2の場合

           2    -   Don't overcommit. The total address space commit
            for the system is not permitted to exceed swap + a
            configurable percentage (default is 50) of physical RAM.
            Depending on the percentage you use, in most situations
            this means a process will not be killed while accessing
            pages but will receive errors on memory allocation as
            appropriate.

            Useful for applications that want to guarantee their
            memory allocations will be available in the future
            without having to initialize every page.

そのため、デフォルトでlinuxがオーバーコミットすることはありません。アプリケーションのメモリがこれより多い場合、コードにバグがある可能性があります。