OOMキラーが適切に機能せず、OSがフリーズする

何年もの間、私のオペレーティングシステムのOOMキラーは適切に動作せず、システムのフリーズにつながります。
メモリ使用量が非常に高い場合、プロセスを強制終了してメモリを解放するのではなく、システム全体が数時間または数日間「フリーズ」（実際には非常に遅くなる）する傾向があります。 記録した最大時間は、リセットを実行するために自分自身を辞任する7日前です。 OOMに到達しようとすると、iowaitは測定不能になる前に非常に高くなります（〜70％）。 ツール：すべてのプログラムがハードドライブから非常に高いスループット（数十MB /秒あたり）で読み取りを行っていることを示しています。 それらのプログラムは何を読んでいますか？


iotop

-ディレクトリ階層？
-実行可能コード自体？
私は正確に今はしません。

[編集]このメッセージを書いた時点（2017年）で、最新のArchLinux（4.9.27-1-lts）を使用していましたが、この問題は数年前から既に経験していました。
さまざまなLinuxディストリビューションと異なるハードウェア構成で同じ問題が発生しました。
現在（2019年）、私は私が持っているuptodateのDebian 9.6（4.9.0）を使用しています16ギガバイトの物理RAM、私のOSがインストールされているSSDのではなく、任意のスワップパーティションを。

持っているRAMの量のため、スワップパーティションを有効にしたくありません。問題の出現を遅らせるだけです。
また、SSDを頻繁にスワップすると、ディスクの寿命が短くなる可能性があります。
ちなみに、スワップパーティションを使用して、または使用せずに試してみましたが、問題の出現を遅らせるだけで、解決策ではないことがわかっています。

私にとってこの問題は、Linuxがキャッシュから重要なデータをドロップするという事実によって引き起こされます。

Linuxが実行中のプログラムの実行可能コードページをドロップしないのではないかと考えています。

この問題を解決するために、いくつかのことを試しました。
1つは（1 GB）に設定/proc/sys/vm/min_free_kbytesすることでした1000000。
この1 GBは空いているはずなので、このメモリは重要なデータをキャッシュするためにLinuxによって予約されると思いました。
しかし、うまくいきませんでした。

また、私はそれを定義することによって、物理メモリのサイズに仮想メモリのサイズを制限し、理論的に大きな音ができても、それを追加するのに便利だと思う/proc/sys/vm/overcommit_memoryに2まともな技術的に可能な私の状況ではないが、アプリケーションの種類理由私が使用するものは、何らかの理由で実際に使用するよりも多くの仮想メモリを必要とします。
ファイル/proc/meminfoによると、Commited_AS値は多くの場合、システムの物理RAMの2倍よりも大きくなっています（16 GB、Commited_ASは多くの場合32 GBを超えています）。

私はこの問題を経験している/proc/sys/vm/overcommit_memoryデフォルト値にする：0、とのために私はそれを定義しているが：1、私はプログラムがで殺されるのが好ましいので、OOMキラー彼らはの戻り値をチェックしていないためではなく、誤って振る舞いますmalloc割り当ては拒否されます。

IRCでこの問題について話していたとき、このまったく同じ問題を経験した他のLinuxユーザーに会ったことがあるので、多くのユーザーがこれに懸念を持っていると思います。
私にとっては、Windowsでさえ高いメモリ使用量を処理できるため、これは受け入れられません。

さらに情報が必要な場合は、提案をしてください、教えてください。

ドキュメント：
https : //en.wikipedia.org/wiki/Thrashing_%28computer_science%29
https://en.wikipedia.org/wiki/Memory_overcommitment
https://www.kernel.org/doc/Documentation/sysctl/vm txt
https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
https://lwn.net/Articles/317814/

彼らはそれについて話します：
なぜLinuxのメモリ不足（OOM）キラーは自動的に実行されず、sysrq-keyで動作するのですか？
OOM-killerがリソース豚を殺さないことがあるのはなぜですか？
OOM Killerのプリロード
強制スワップでOOM-killerをトリガーすることは可能ですか？
OOM状況に近い高遅延を回避する方法
https://lwn.net/Articles/104179/
https://bbs.archlinux.org/viewtopic.php?id=233843

私は理由として（同じものの）2つの説明を見つけたkswapd0はない一定のディスクの読み取りが起こる OOMキラーは、問題のあるプロセスを殺すだけでなく前に：

1. このaskubuntu SEの回答とコメントをご覧ください
2. UNIX SEでの回答とこの回答に対するDavid Schwartzのコメントを参照してください。

ここで、1からのコメントを引用します。これは、すべてがフリーズしている間に常にディスク読み取りが行われた理由について本当に目を開いたものです。

たとえば、スワップがゼロで、システムのRAMがほとんどなくなっている場合を考えてください。カーネルは、たとえばFirefoxからメモリを取得します（Firefoxはディスクからロードされた実行可能コードを実行しているため、これを行うことができます-コードは必要に応じてディスクから再度ロードできます）。FirefoxがそのRAMにN秒後に再度アクセスする必要がある場合、CPUはLinuxにRAMを解放する（たとえば、別のプロセスからRAMを取得する）「ハードフォールト」を生成し、ディスクから欠落データをロードして、Firefoxがいつも。これは通常のスワッピングとかなり似ており、kswapd0がそれを行います。–ミッコランタライネン2月15日13:08

誰かがこの動作を無効にする方法がある場合（おそらく、どのオプションでカーネルを再コンパイルしますか？）、できるだけ早くお知らせください！感謝します！

UPDATE：私はこれまで見つけた唯一の方法は、カーネルにパッチを適用することです、そして、それはスワップ無効になって私の作品（すなわち。CONFIG_SWAP is not setしかしスワップと他の人のための仕事は、それが有効になっていない）ようです。この質問内のパッチを参照してください。

メモリコントローラーのmemory.minパラメーターcgroups-v2が役立ちます。

つまり、引用させてください：

ハードメモリ保護。cgroupのメモリ使用量が有効な最小境界内にある場合、cgroupのメモリはどのような条件下でも再利用されません。保護されていない再生可能なメモリがない場合、OOMキラーが呼び出されます。

ソース：https : //www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html