長年にわたり、OOMキラーオペレーティングシステムが正しく動作しないため、システムがハングします。
メモリ使用量が非常に高いと、システム全体が「停止」する傾向があります（実際には極度にゆっくりと）時間でも空、メモリを確保するためにプロセスを終了する代わりに。
私が記録した最長期間は7日で、その後リセットのために終了しました。
OOMに到達しようとすると、待つ測定できなくなる前には非常に高いです（～70％）。
このツールは、iotop非常に高いスループット（数十MB /秒）で自分のハードドライブから読み取る各プログラムを示しています。
そのプログラムは何を読んでいますか？
- ディレクトリ階層？
- 実行可能なコード自体？
今はよくわかりません。
[編集済み] この記事を書いた時点（2017）では、最新のArchLinux（4.9.27-1-lts）を使用していますが、数年前にこの問題が発生しました。
他のLinuxディストリビューションとは異なるハードウェア構成で同じ問題が発生しました。
現在（2019）私は最新のDebian 9.6（4.9.0）を使用しています。16ギガバイト物理RAM、OSが搭載されたSSD、なし交換分割。
私が持っているメモリ量のため、スワップパーティションをアクティブにしたくありません。これは、スワップパーティションが問題の発生を遅らせるためです。
さらに、SSDを頻繁に交換すると、ディスクの寿命が短くなる可能性があります。
ところで、スワップパーティションを使用または使用せずにこれを試しましたが、問題が解決せずに遅延するだけであることがわかりました。
私にとってこの問題は、Linuxが重要なデータを削除したために発生しました。隠れ家、毎回ハードドライブのすべての内容を読む必要があるため、システムがハングします。
Linuxが実行中のプログラムの実行可能コードページを削除しないかどうか疑問に思います。これは、通常、大量のデータを読み取らないプログラムがこの場合にこのように動作する理由を説明します。
この問題を解決するためにいくつかの方法を試しました。 1つは（1GB）に
設定されています。このため/proc/sys/vm/min_free_kbytes1000000
1GB無料で維持する必要があり、このメモリはLinuxで重要なデータをキャッシュするために予約されていると仮定します。
しかし、それはうまくいきませんでした。
また、理論的には良く見えますが、toを定義して仮想メモリのサイズを実際のメモリのサイズに制限するのは技術的であるため、一部の点を付け加えると/proc/sys/vm/overcommit_memory便利だと思います。2何らかの理由で私が使用している仮想メモリには、効果的に使用できるよりも多くの仮想メモリが必要です。
ドキュメントによると、/proc/meminfoこのCommited_AS値は通常私のシステムの物理メモリ（16GB、送信_AS通常>32GB)。
/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
ベストアンサー1
kswapd0がディスクから読み続ける理由の2つの説明（同じもの）が見つかりました。発生するOOM-killerが問題のあるプロセスを終了する前に：
- 回答とコメントを見るこのaskubuntu SEの答え
- 答えとDavid Schwartzのコメントを見るこの答えはUNIX SEにあります
ここに1.のコメントを引用します。すべてが大丈夫だったが、なぜディスクから読み続けたのかを目覚めさせました。冬の王国:
たとえば、スワップ領域がなく、システムのRAMがほとんど不足している状況を考えてみましょう。カーネルはたとえばFirefoxからメモリを取得します（Firefoxがディスクからロードされた実行コードを実行しているため、これを行うことができます。コードは必要に応じてディスクから再ロードできます）。 FirefoxがN秒後にそのRAMに再びアクセスする必要がある場合、CPUはLinuxがいくつかのRAMを解放し（たとえば、他のプロセスからいくつかのインポート）、ディスクから欠落しているデータをロードしてからFirefoxを実行し続ける「ハードエラー」 」を生成します。通常。これは kswapd0 が実行する通常のスワップと非常に似ています。 – Mikko Rantalainen 2月15日, 13:08
誰もがこの動作を無効にする方法を知っている場合（たぶんカーネルを再コンパイルするためにどのようなオプションが使用されますか？）、できるだけ早く教えてください！とても感謝しています！
修正する:これまで私が見つけた唯一の方法は、カーネルをパッチすることです。これは、スワップが無効な状態で（たとえば）機能しCONFIG_SWAP is not setましたが、スワップが有効になっている他のユーザーには機能しませんでした。〜らしい;内側のパッチを見てくださいこれ質問。