OOM キラーが自動的に呼び出されない理由は、メモリ不足に近づいているときに、システムが完全に遅くなり、応答しなくなるためです。 y、実際にはメモリ不足の状況には達していません。
単純化しすぎて、ほぼ完全な RAM には 3 種類のデータが含まれています:
<オール>
メモリ不足の状況では、私が知る限り、Linux カーネルは kswapd0 です。 カーネル スレッドは、データの損失と機能の損失を防ぐために 1. と 2. を捨てることはできませんが、現在実行されていないフォーム プロセスであるメモリ ファイルにマップされたデータを RAM から少なくとも一時的に自由に削除できます。
これはディスクのスラッシングを伴う動作ですが、常にデータを破棄してディスクから再読み取りすることは、プロセスの必要な削除/強制終了と解放を回避するか、少なくとも延期するのと同じくらい有用であると見なすことができます。記憶を失い、高い 価格:パフォーマンス。
[load pages from disk to ram with code of executable of process 1]
[ run process 1 ]
[evict pages with binary of process 1 from ram]
[load pages from disk to ram with code of executable of process 2]
[ run process 2 ]
[evict pages with binary of process 2 from ram]
[load pages from disk to ram with code of executable of process 3]
[ run process 3 ]
[evict pages with binary of process 3 from ram]
....
[load pages from disk to ram with code of executable of process 1]
[ run process 1 ]
[evict pages with binary of process 1 from ram]
明らかに IO コストが高く、システムが応答しなくなる可能性がありますが、技術的にはまだ完全に使い果たされていません。
ただし、ユーザーの観点からは、ハング/フリーズし、結果として応答しない UI は、単純にプロセスを強制終了するよりも、実際には好ましくない可能性があります (たとえば、ブラウザー タブのメモリ使用量が根本的な原因/原因である可能性が非常に高い可能性があります)。
Magic SysRq はシステムの無応答による影響が少ないため、OOM を手動で開始するための Magic SysRq キー トリガーが優れているように思われる質問が示されているのは、このような場合です。
プロセスをまったく維持することが重要なユースケースがあるかもしれませんが (パフォーマンス デスクトップの場合、ユーザーはフリーズした UI よりも OOM キラーを好む可能性があります。 stackoverflow のこの回答では、このような状況でメモリからクリーン マップされた fs でバックアップされたファイルを除外すると主張するパッチがあります。
ストレス テスト中に、ファイル /sys/fs/cgroup/memory/memory.oom_control を監視できます。
または
最後のロックアップの前後に変更されたかどうかを確認するために、最終更新日を確認できます。これは、それが仕事をしようとしていたかどうかを教えてくれます.
under_oom 0
それはあなたの問題です:
under_oom 0 or 1 (if 1, the memory cgroup is under OOM, tasks may
be stopped.)
1 に設定されている場合は、それが oom 制御下にあることを意味します。有効。
0 に設定すると、そのように oom の制御下にありません。無効です。