☰

Linux OOM（メモリ不足）キラーが自動的に実行されず、sysrq-keyで動作するのはなぜですか？

tag-icon • tag-icon linux out-of-memory
Linux OOM（メモリ不足）キラーが自動的に実行されず、sysrq-keyで動作するのはなぜですか？

メモリ不足のOOMの状況が発生すると、LinuxボックスのUIが長い間完全に停止することがわかりました。

Magic-sysrq-keyを設定した後、OOM-> UIレスポンスがない状況が発生し、ログに示されているようにOOMがプロセスを終了/終了させて​​OOMの状況を解決することがecho 1 | tee /proc/sys/kernel/sysrqできました。Alt-Sysrq-fdmesg

私の問題は今です。 GUIがフリーズしているかのようにLinuxが応答しませんが、キーの組み合わせAlt-Sysrq-fで手動で実行するのと同じOOM-Killerを実行しないのはなぜですか？

OOMの「停止」状況では、システムが応答せず、タイムリーな（<10秒）応答（tty3に切り替える）も許可しないことを考慮すると、カーネルは応答がないことを認識する必要がありますが、まだそうでないと仮定する必要があります。 OOMCtrl-Alt-F3セルフコール -Alt-Sysrq-f

以下は、説明されている動作に影響を与える可能性があるいくつかの設定です。

$> mount | grep memory
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
$> cat /sys/fs/cgroup/memory/memory.oom_control 
oom_kill_disable 0
under_oom 0
oom_kill 0

私が理解している限り、メモリcgroupはOOMを有効または無効にしません（明らかにOOM_killを有効または無効にするには妥当な理由が必要です。出力が正しく解釈されていないため、under_oom 0まだ少し不明瞭です）。

答え1

OOM-killerが自動的に呼び出されない理由は、システムが完全に遅く応答がないにもかかわらずメモリ不足y、実際にメモリ不足の状況に達していません。

単純化しすぎると、ほぼ完全なメモリには3種類のデータが含まれます。

  1. 必須カーネルデータ
  2. 基本プロセスデータページ（つまり、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は、単にプロセス（つまり、メモリ使用量が根本原因/犯人である可能性が最も高いブラウザタブのプロセス）を終了するよりも優れていません。最初。 )

質問からわかるように、これはマジックSysRqキーMagic SysRq はシステム応答の影響を受けにくいため、OOM のトリガーを手動で開始することをお勧めします。

プロセスを保存することが重要なユースケースがあるかもしれませんが（パフォーマンス）コスト、デスクトップユーザーの場合は、固定UIの代わりにOOMキラーを好むことができます。この状況では、メモリからきれいにマップされたファイルシステムサポートファイルを除外すると主張するパッチがあります。stackoverflowへの回答。

答え2

ストレステスト中に /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によって制御されません。障害者。

関連情報