Debian 9.4、Linux 4.9
時々、RAM にほとんど収まらないものをコンパイルしたり、不正なプロセスが突然、使用可能なメモリを超えてメモリを消費し始めたりします。プロセスが使用可能な RAM を超えると、ゼロ スワップを有効にしているにもかかわらず (スワップなしはこれを回避する試みでした)、Linux はディスクをスラッシングし始めます。mmap現在実行中のバイナリの ped 部分のようなものを破棄して再ロードし始めるのでしょうか?
この時点で、X セッションはすぐに応答しなくなり、X セッション全体が終了して再度ログインできるようになるまで、数十分間待つことしかできません。
解決策を探してみましたが、何も機能しないようです。OOM キラーはこのプロセスをキャッチせず、vm.overcommit_memory=2GDM と Gnome でログインすることすらできません。
方法はあるかLinuxにスワップを一切しないように指示する? そうすれば、少なくとも、不正なプロセスが失敗したことによって強制終了される可能性は得られますしmalloc、そうでなくても、応答しないマシンを見つめながら待つ必要はなくなります。
または、このシナリオを管理する他のヒントはありますか?
答え1
利用可能な RAM のほとんどすべて、あるいはそれ以上を必要とするソースをコンパイルする場合、おそらく唯一のパフォーマンスの高いソリューションは実際の RAM を追加することです。そうは言っても、非常に大量のスワップ (RAM の 2 倍または 3 倍など) を追加し、/proc/sys/vm/swappiness1 などの低い値に設定して (カーネル 3.5 以降では 0 に設定するとスワップが完全に無効になることに注意してください)、必要な場合にのみスワップが使用されるようにすることができます。これにより、スラッシングが最小限に抑えられるはずです。
答え2
RAM やスワップ領域の追加を推奨する人がいるのは理解できません。動作の悪いアプリケーションがそれをすべて消費し、問題を再現する可能性があります。
この種のフリーズは Linux カーネルの重大なアーキテクチャ上のバグです。フリーズが発生したら回復する唯一の方法は、マジック キー (alt+sysrq+f) で OOM を強制することです。カーネル ログを見ると、何が強制終了されたか、またその理由がわかります。
いくつかのプロジェクトでは、ユーザー空間からこのフリーズを防止しようとしています。例として earlyOOM を参照してください。