3
メモリーが制限されたLXCコンテナー内のアプリケーションがディスクに大きなファイルを書き込むと、なぜOOMによって強制終了されるのですか？
EDIT2：この問題は3.8.0-25-generic＃37-Ubuntu SMPにも存在するようです 編集：「なぜddを使用してファイルに書き込むことによってLinuxのメモリ不足マネージャーがトリガーされるのですか？」という元のタイトルからの質問を変更しました。以下で説明する一般的な問題について心配していることをよりよく反映するために： メモリ制限（300MBに設定）を超えるサイズのファイルを書き込むと、LXCコンテナーでOOMキラーがプロセスを強制終了するという厄介なシナリオに遭遇しています。実際には512 MBのRAMしかないXen仮想マシン（EC2 t1.micro）でアプリケーションを実行しても問題は発生しないため、コンテナーのメモリ制限に関するファイルバッファリングに問題があるようです。 簡単な例として、ddによって書き込まれた大きなファイルがどのように問題を引き起こすかを示します。繰り返しますが、この問題はすべてのアプリケーションを悩ませています。アプリケーションのキャッシュが大きくなりすぎるという一般的な問題を解決しようとしています。「dd」を機能させる方法を理解しています。 シナリオ： LXCコンテナーで、memory.limit_in_bytesが300 MBに設定されています。 私は次のように500 MB以下のファイルをddしようとします。 dd if=/dev/zero of=test2 bs=100k count=5010 ほぼ20％の時間、Linux OOMマネージャーはこのコマンドによってトリガーされ、プロセスが強制終了されます。言うまでもなく、これは非常に意図しない動作です。ddは、コンテナ内で実行されるプログラムによる実際の「有用な」ファイル書き込みをシミュレートすることを目的としています。 詳細：ファイルキャッシュが大きくなる（260 MB）一方で、rssとファイルマップはかなり低いままのようです。以下は、書き込み中にmemory.statがどのように見えるかの例です。 cache 278667264 rss 20971520 mapped_file 24576 pgpgin 138147 pgpgout 64993 swap 0 pgfault 55054 pgmajfault 2 inactive_anon 10637312 active_anon 10342400 inactive_file 278339584 active_file 319488 unevictable 0 hierarchical_memory_limit 300003328 hierarchical_memsw_limit …