マシンのメモリが不足すると、予期しない動作が発生します。
32GBのRAMを搭載したInteli7-6700を使用しており、Vanilla4.14.8カーネルを搭載したArchLinuxを実行しています。SSDディスク上の暗号化されたLVMボリュームに32GBのスワップがあります。
通常の操作では、他のもの(XFCE、Firefoxなど)とともに、QEMU/KVMゲストをいくつか実行します。通常のメモリ使用量は約20〜30%で、スワップはほとんどありません。
しかし、メモリを大量に消費するもの(たとえば、大きなファイルを圧縮するために7za a -md=29
)を実行すると、メモリ使用量が100%になると、システムがハング/フリーズします。キーボードとマウスが完全に応答を停止し、ディスプレイがフリーズし、ディスクアクティビティが停止し、マシンへのTCP接続がSYNフェーズでハングします。この状況から回復する唯一の方法は、マシンの電源を入れ直すことです。 。
ハングする直前の瞬間に、スワップスペースが実質的に使用されていないことがわかります。もちろん、スワップは有効になっており、メモリに関連する特定のsysctl設定を使用していません(特に、vm.swappinessのデフォルト値は60です)。
私が理解していないのはこれです:
私はカーネルの専門家ではありませんが、私が理解しているように、メモリが不足したときにシステムがフリーズ/ハングすることは想定されていません。私が期待するのはこれです:
7za
を強制終了することになっていますしたがって、実際には、メモリ不足を防ぐための3つの独立したメカニズムがありますが、それらはすべて失敗しているように見えます。知らない微妙な問題(ゲストVMのメモリバルーニング、ロックされたメモリなど)があるかもしれないことはわかっていますが、私が見ている動作を説明するものは何も考えられません。
誰かがここで何が起こっているのか、そしてその理由を説明できますか?私は何かが足りないのですか?ぶら下がりを決定論的に防ぐために何かをすることはできますか?
編集:
私はいくつかの差分テストを実行しましたが、次のことがわかりました。
問題は何らかの形でLVMに関連しているように見えます。どちらの場合も同じ物理パーティションを使用したので、ディスクとは関係ありません。テスト中、vm.swappinessを60(デフォルト)のままにしました。
補足として、ある特定のテスト中に、htopで、マシンがフリーズする直前にスワップバーに1つの「ノッチ」が表示されていることに気付きました。そのため、カーネルは実際にスワップを使用し始めましたが、それは約3秒間しか続きませんでした。
問題は簡単に再現できるはずです。
更新:
これをフォローアップしている人のために、問題はLVM上でスワップスペースを使用することに固有であると判断しました(暗号化されているかどうかは関係ありません)。これは4.xカーネルでテストされましたが、sysctlパラメーターを調整することでこのハングを回避できませんでした。現在、5.xに関する情報はありません。私にはカーネルのバグのようです。
同様の結果が発生するのを見てきましたが、問題はメモリの不足ではありません。これは、ルートパーティション/ボリュームのスペースを消費するプロセスです。
例えば。通常、これは/ tmpまたは/内の他のファイルシステムへの過度の書き込みである可能性があります。カーネルは、書き込まれていないメモリをRAMバッファに格納するために、可能な限り(それほど多くはありませんが)スワップアウトします。かなり迅速にこれは失敗し、すべてが停止します。
通常、警告メッセージが発行されますが、特にストレージに貪欲なプロセスでは表示されない場合があります。