web-dev-qa-db-ja.com

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

メモリ不足のOOM状態に陥ると、LinuxボックスのUIが非常に長い間完全にフリーズすることがわかりました。

Magic-sysrq-keyをセットアップしてからecho 1 | tee /proc/sys/kernel/sysrqを使用し、OOM-> UIに応答しない状況が発生するとAlt-Sysrq-fを押すことができ、dmesgログが示すようにOOMが終了しました/ killプロセスを実行し、これによりOOM状況を解決します。

私の質問は今です。 GUIがフリーズするほどLinuxが応答しなくなったのに、Alt-Sysrq-fキーの組み合わせで手動でトリガーしたのと同じOOM-Killerがトリガーされなかったのはなぜですか？

OOMが「フリーズ」した状況では、システムが非常に応答しないため、Ctrl-Alt-F3（tty3への切り替え）のヒットに対してタイムリーな（<10秒）応答さえできないため、カーネルが認識している必要があると想定する必要があります。応答がないが、それでもAlt-Sysrq-f OOM-Killerを起動しなかったのはなぜですか。

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

$> 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まだはっきりしていません）

linuxout-of-memory
7
humanityANDpeace

OOM-killerが自動的に呼び出されない理由は、システムがメモリ不足yに近づくと、すでに完全にスローダウンして応答しなくなっているためです。 、実際にはメモリ不足の状態に達していません。

ほとんど簡略化されたRAMには3種類のデータが含まれています。

  1. カーネルデータ、それは不可欠です
  2. 重要なプロセスデータのページ（プロセスがRAMでのみ作成したデータなど）
  3. 必須ではないプロセスデータのページ（たとえば、実行可能ファイルのコードなど、ディスク上のコピーがファイルシステムにあり、現在メモリにマップされている間、使用時にディスクから「再読み込み」できるデータ）

メモリ不足の状況では、Linuxカーネルは私が知る限りkswapd0カーネルスレッドは、データの損失と機能の損失を防ぐために、1と2を捨てることはできませんが、現在一時的ではないフォームプロセスであるRAMから、メモリファイルにマップされたデータを少なくとも一時的に削除できますランニング。

これは disk-thrashing を伴う動作ですが、常にデータを破棄してディスクから再読み取りすることは、プロセスの削除/強制終了を回避または少なくとも延期するので役立つと見なすことができます。メモリを解放すると同時に失うことで、高価格：パフォーマンス。

[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は、プロセスを強制終了するよりも実際には好ましくない場合があります（たとえば、メモリ使用量が原因である可能性が非常に高いブラウザタブのプロセス）で始まる。）

これは、質問が示したように、手動でOOMを起動する Magic SysRq key トリガーは素晴らしいように見えます。MagicSysRqはシステムの無応答性による影響が少ないためです。

プロセスをすべて（performance）のコストで維持することが重要なユースケースがあるかもしれませんが、デスクトップの場合、使用はOOM-killerよりも優先されます。フリーズされたUI。この stackoverflowの回答 には、このような状況でクリーンにマップされたfsバッキングファイルをメモリから除外すると主張するパッチがあります。

2
humanityANDpeace

ストレステスト中は、/ 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コントロールの対象外になります。無効。

2
Michael Prokopec