OOMキラーが機能していませんか？

私の理解では、システムに空きメモリがなくなると、カーネルはプロセスを強制終了してメモリを回復します。しかし、私のシステムでは、これはまったく起こりません。

システムで使用可能なメモリ（たとえば、数百万の文字列を含む配列）よりもはるかに多くのメモリを割り当てる単純なスクリプトを想定します。このようなスクリプトを（通常のユーザーとして）実行すると、システムが完全にフリーズするまですべてのメモリが取得されます（SysRQ REISUBのみが機能します）。

ここで奇妙な部分は、スワップパーティションがマウントされているかどうかに関係なく、コンピューターがフリーズすると、ハードドライブのLEDがオンになり、コンピューターが再起動されるまでそのままの状態が続くことです。

だから私の質問は：

1. この動作は正常ですか？通常のユーザーとして実行されたアプリケーションがこのようにシステムをクラッシュさせる可能性があるのは奇妙です...
2. Ubuntuがメモリを大量に（または最大に）取得したときにそれらのアプリケーションを自動的に強制終了させる方法はありますか？

追加情報

• Ubuntu 12.04.3
• カーネル3.5.0-44

• RAM：4GBから〜3.7GB（グラフィックカードと共有）。*

  $ tail -n+1 /proc/sys/vm/overcommit_*
  ==> /proc/sys/vm/overcommit_memory <==
  0
  
  ==> /proc/sys/vm/overcommit_ratio <==
  50
  
  $ cat /proc/swaps
  Filename                Type        Size    Used    Priority
  /dev/dm-1                               partition   4194300 344696  -1
  

公式/proc/sys/vm/*ドキュメントから：

oom_kill_allocating_task

これにより、メモリ不足の状況でOOMトリガータスクを強制終了できます。

これがゼロに設定されている場合、OOMキラーはタスクリスト全体をスキャンし、ヒューリスティックに基づいて殺すタスクを選択します。これは通常、強制終了時に大量のメモリを解放する不正なメモリ占有タスクを選択します。

これがゼロ以外に設定されている場合、OOMキラーはメモリ不足状態を引き起こしたタスクを強制終了します。これにより、高価なタスクリストスキャンが回避されます。

panic_on_oomが選択されている場合、oom_kill_allocating_taskで使用される値よりも優先されます。

デフォルト値は0です。

要約すると、を設定oom_kill_allocating_taskすると1、システムをスキャンして強制終了するプロセスを探しますが、これは高価で時間がかかるタスクであり、カーネルはシステムのメモリ不足を引き起こしたプロセスを強制終了します。

私自身の経験から、OOMがトリガーされると、カーネルにはそのようなスキャンを実行するのに十分な「強度」がなくなり、システムがまったく使用できなくなります。

また、問題の原因となったタスクを強制終了するだけの方が明らかになるため0、デフォルトで設定されている理由を理解できません。

テストのため/proc/sys/vm/に、次の再起動時に元に戻す適切な擬似ファイルに書き込むことができます。

echo 1 | sudo tee /proc/sys/vm/oom_kill_allocating_task

永続的な修正/etc/sysctl.confを行う/etc/sysctl.d/には、.conf拡張子を付けて、/etc/sysctl.d/local.confたとえば、以下の新しいファイルに以下を書き込みます：

vm.oom_kill_allocating_task = 1

更新：バグが修正されました。

テレサの答えは問題を回避するのに十分であり、良いです。

さらに、バグ報告を提出しました。これは間違いなく壊れた動作だからです。

Earlyoomを試すことができます。これは、ユーザー空間で動作し、OOM状況で最大のプロセスを殺そうとするOOMキラーです。

まず、13.10への更新（クリーンインストール、データの保存）をお勧めします。

更新したくない場合は、vm.swappinessを10に変更し、RAMに問題がある場合はzRAMをインストールします。