何年もの間、OOMキラー オペレーティングシステムが正常に動作せず、システムがフリーズする原因になります。
メモリ使用量が非常に多い場合、システム全体が「フリーズ」する傾向があります（実際、非常に 遅い）時間 または日 、メモリを解放するためにプロセスを強制終了する代わりに。
記録した最大値は、リセットを操作するために辞任する7日前です。
OOMに到達しようとすると、 iowait 測定不能になる前に、非常に高い（〜70％）。
ツール：iotop すべてのプログラムが私のハードドライブから非常に高いスループット（数十MB /秒）で読み取っていることを示しています。
それらのプログラムが読み取っているものは何ですか？
–ディレクトリ階層？
–実行可能コード自体？
今は正確ではありません。
[編集]このメッセージを書いた時点（2017年）では、最新のArchLinux（4.9.27-1-lts）を使用していましたが、すでに何年も前にこの問題を経験していました。
同じ問題を経験しましたさまざまなLinuxディストリビューションとさまざまなハードウェア構成を使用しています。
現在（2019）、最新のDebian 9.6（4.9.0）を使用しています
16 GB 物理RAM、OSがインストールされているSSDであり、スワップはありません パーティション。
RAMの量が多いため、スワップパーティションを有効にしたくありません。問題の発生が遅れるだけです。
また、SSDを頻繁にスワップすると、寿命が短くなる可能性があります。ディスク。
ちなみに、私はすでにスワップパーティションの有無にかかわらず試しましたが、問題の発生を遅らせるだけで、解決策ではないことが証明されました。
私にとってこの問題は、Linuxがキャッシュから重要なデータをドロップするという事実が原因です。 、ハードドライブから毎回すべてを読み取る必要があるため、システムがフリーズします。
Linuxが実行中のプログラムの実行可能コードページをドロップしないのではないかとさえ思います。これは、通常は多くのデータを読み取らないプログラムがこの状況でこのように動作する理由を説明します。
この問題を解決するために、いくつかのことを試しました。
1つは、/proc/sys/vm/min_free_kbytesを設定することでした。 1000000へ （1 GB）。
この 1 GB このメモリは、重要なデータをキャッシュするためにLinuxによって予約されると思いました。
しかし、機能しませんでした。
また、/proc/sys/vm/overcommit_memoryを定義することにより、理論的には素晴らしいと思われる場合でも、仮想メモリのサイズを物理メモリのサイズに制限することを追加すると便利だと思います。 2へ 私が使用している種類のアプリケーションは、何らかの理由で効果的に使用するよりも多くの仮想メモリを必要とするため、私の状況では技術的に適切に可能ではありません。
ファイル/proc/meminfoによると 、Commited_AS 多くの場合、値はシステムの物理RAMの2倍（16 GB、 Commited_AS ）よりも高くなります。 多くの場合>32GBです。
/proc/sys/vm/overcommit_memoryでこの問題が発生しました デフォルト値： 、そしてしばらくの間、私はそれを次のように定義しました：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
承認された回答：
kswapd0がなぜするのかについて（同じことの）2つの説明を見つけました 一定のディスク読み取り発生 OOM-killerが問題のプロセスを強制終了するかなり前に：
- このaskubuntuSEの回答の回答とコメントを参照してください
- UNIXSEに関するこの回答に対する回答とDavidSchwartzのコメントを参照してください
ここで1からのコメントを引用します。これは、すべてがフリーズしているときにディスクの読み取りが一定になっている理由について、本当に目を開かせました。
たとえば、スワップがゼロで、システムのRAMがほぼ不足している場合を考えてみます。
カーネルは、たとえばFirefoxからメモリを取得します（Firefoxはディスクからロードされた実行可能コードを実行しているため
これを実行できます。コードは必要に応じてディスクから再度ロードできます
）。その後、FirefoxがN
秒後にそのRAMに再度アクセスする必要がある場合、CPUは「ハードフォールト」を生成し、Linuxに
一部のRAMを解放させます（たとえば、別のプロセスから一部のRAMを取得します）。
ディスクからデータが欠落している場合は、Firefoxを通常どおり続行できます。
これは通常のスワッピングと非常によく似ており、kswapd0が実行します。 –ミッコ
ランタライネン2月15日13:08
この動作を無効にする方法（カーネルをどのオプションで再コンパイルするか）について誰かが知っている場合は、できるだけ早く知らせてください！どうもありがとうございました！
更新： これまでに見つけた唯一の方法は、カーネルにパッチを適用することです。これは、スワップを無効にした場合に機能します（つまり、CONFIG_SWAP is not set ）ただし、スワップが有効になっている他のユーザーには機能しないようです。この質問の中のパッチを参照してください。