OOMキラーをもっと早く介入させることは可能ですか？
私は開発システムを調整して、信頼性を最大限に高めようとしています。スワップを無効にしたのは、GUIを使用すると、ほとんどの場合、マシンが応答しなくなり、使用できなくなるためです。それにもかかわらず、攻撃的なアプリケーションがメモリを使い果たした場合、速度のコストを最大限に活用するために、いくつかのメカニズムが作動するように思われます。ハードドライブのスワップ操作はありませんが、システムは同様に応答しなくなります。そのため、システムがメモリゲインに特別な努力をする前に、OOMキラーを起動させたいと思います。たとえば、空き物理メモリが100 MB未満の場合に動作するようにOOMキラーを構成することはできますか？
私もその問題に苦労しました。私は、システムが何があっても応答性を維持したいだけであり、数分待つよりもプロセスを失うことを好みます。カーネルoom killerを使用してこれを実現する方法はないようです。
しかし、ユーザースペースでは、私たちがやりたいことは何でもできます。そこで、利用可能なRAMが10を下回ると（RSSによって）最大のプロセスを強制終了するEarly OOM Daemon（ https://github.com/rfjakob/earlyoom ）を書きました％。
アーリールームなしでは、 http://www.unrealengine.com/html5/ を数回起動することで、私のマシン（8GB RAM）を簡単にロックすることができました。今、罪のあるブラウザのタブは手に負えなくなる前に殺されます。
カーネルのデフォルトのポリシーは、空き物理メモリがある限り、アプリケーションが仮想メモリを割り当て続けることを許可することです。物理メモリは、アプリケーションが割り当てた仮想メモリにタッチするまで実際には使用されないため、アプリケーションはシステムのメモリよりもはるかに多くのメモリを割り当てることができ、後でタッチを開始して、カーネルがメモリ不足になり、メモリ不足が発生します。 of memory（OOM）killer。ただし、負荷のかかるプロセスが強制終了される前は、ディスクキャッシュが空になるため、キャッシュが再充填されるまで、システムの応答がしばらく遅くなります。
/proc/sys/vm/overcommit_memoryに2の値を書き込むことで、デフォルトのポリシーを変更してメモリのオーバーコミットを禁止できます。 /proc/sys/vm/overcommit_ratioのデフォルト値は50であるため、カーネルはアプリケーションがram + swapの50％以上を割り当てることを許可しません。スワップがない場合、カーネルはアプリケーションがRAMの50％以上を割り当てることを許可せず、残りの50％はキャッシュ用に空けたままにします。これは少し過剰な場合があるため、この値を85％程度に増やして、アプリケーションがRAMの最大85％を割り当てて、キャッシュに15％を残すことができます。
私にとって、vm.admin_reserve_kbytes = 262144を設定すると、まさにこのことを行います。システムが完全に応答しなくなる前に、OOMキラーが介入します。
他の答えには自動解決策がありますが、手に負えなくなったときにSysRqキーを有効にすると役立つ場合があります。 SysRqキーを使用すると、手動でカーネルにメッセージを送信し、ユーザースペースが完全にフリーズした場合でも、安全な再起動（SysRQ + REISUBを使用）などの操作を実行できます。
カーネルがリクエストをリッスンできるようにするには、kernel.sysrq = 1を設定するか、ビットマスクで使用する可能性のある関数のみを有効にします（ドキュメント here ）。たとえば、kernel.sysrq = 244は、上記の安全な再起動に必要なすべてのコンボと、SysRq + FによるOOMキラーの手動呼び出しを有効にします。