回答:
システムは実際には(カーネルがハングしたという意味で)「フリーズ」せず、むしろ非常に応答しなかったに違いありません。おそらく、非常に激しく交換するだけで、インタラクティブなパフォーマンスとシステムスループットが石のように低下する可能性があります。
スワップをオフにすることもできますが、これは問題をパフォーマンスの低下からOOMで強制終了したプロセス(およびその原因となるすべての楽しみ)に変更するだけでなく、使用可能なディスクキャッシュが少ないためパフォーマンスが低下します。
代わりに、プロセスごとのリソース制限(一般にrlimit
andまたはor と呼ばれるulimit
)を使用して、1つのプロセスがとんでもない量のメモリを使用してスワッピングを引き起こす可能性を削除できますが、それにより、システムが提供するよりも少し多くのメモリが必要だったため、不便な瞬間がありました。
大量のメモリ使用量を引き起こす可能性のあることを行うとわかっている場合は、おそらくmlockall()
シェルプログラムを実行してからシェルを実行するラッパープログラムを作成できます。それはメモリ内に保持し、取得する可能性が高い「応答性の高いコアを維持する」ことに最も近いものになります(CPUが過剰に使用されていることが問題ではないため)。
個人的に、私はリソース制御の「愚かなことをしないでください」メソッドにサブスクライブします。あなたがルートを持っている場合は、システムへの損傷のすべてのソートを行うには、そうすることができます何でもあなたは危険なビジネスである可能性の高い結果を知らないということを。
ulimit
。クリティカルではない環境でクエリの効果を検証せずに運用環境でクエリを変更する場合、それが根本的な問題です。
Tronicのコメントで前述したように、キーボードの組み合わせSysRq-で直接OOM-killer(out of memory killer)を呼び出すことができFます。
SysRqキーは通常PrtSc、キーボードのキー内で結合されます。
OOM-killerはいくつかのプロセスを強制終了し(-es)、システムは再び応答します。OOM-killerへの直接アクセスはデフォルトでは有効になっていない可能性があります。この質問をチェックアウトして、ステータスの確認方法や有効化方法を確認してください。
PS:これはとても助かりました。これは、Chromeやメモリ欲張りソフトウェアが原因である場合、これがその問題に関する最も有用なアドバイスであるという意見に同意します。しかし、OOM-killerはいくつかの本当に重要なプロセスを殺す可能性があることに注意してください。慎重に使用してください。
これは2007年以降に知られているバグです- 高いメモリ使用量でシステムがフリーズするを参照してください。
この状況では、Windowsは1つ以上のアプリケーションを閉じるようにユーザーに警告するダイアログを表示します。
カーネルを再コンパイルしたい場合は、この質問のセクションからパッチを試すことができますEDIT
:https : //stackoverflow.com/q/52067753/10239615高いメモリ圧迫時
にActive(file)
ページを排除しないため、OOM-killerが許可されますカーネルは、OSのフリーズの原因となるすべてのプロセスの実行可能コードページのディスクからの一定の再読み取りに数分を費やす必要がなくなるため、ほぼ瞬時にトリガーします。
これは特に防ぐのが難しいものです。カーネルがスワッピングを開始するためです。1つの解決策は、スワップをオフにすることです。スワップを開始するのではなく、システムのメモリが不足すると、カーネルはいくつかのプロセスを強制終了します。通常、正しいプロセスを選択して強制終了しますが、応答しないシステムを使用するよりも、ランダムプロセスを強制終了する方が適切です。
サーバーには十分なRAMがあり、スワップスペースを使用し始めると、とにかく何かが間違っていることを意味するため、これはサーバーにとって特に優れたソリューションとなります。ただし、デスクトップには通常スワップスペースが必要なので、デスクトップに適したソリューションはないと思います。特にメモリリークの疑いがある場合は、サーバーのスワップスペースをオフにします。