マシンがフリーズしている原因を知るにはどうすればよいですか?


10

このマシンでArchを実行しています:

3.40GHz i7ヘキサコア(4930K)

16 GB DDR3 1600 MHz RAM

Raid0の2xSamsung 840 EVO SSD(BTRFS raidを使用)

いくつかのVM(2または3)を備えたArchでVMwareを実行し、それぞれに約2〜4コア、およびそれぞれ2 GBのRAMを与えると、システムがランダムにフリーズし始めます。数分ごとに、システムは10〜30秒の間フリーズし、その後再び動き始めます。VMをシャットダウンするまで、30秒後にフリーズします。システムがフリーズしてもマウスは正常に動きますが、アプリケーションはホスト上で応答を停止します-VMwareが応答しない、Firefox(ホスト上でも開いている)が応答しない、など。

フリーズが発生したときに、プロセスモニターを実行している場合、vmwareによって最大化されたいくつかのコアが表示されますが、同時に、他の未使用のコアがあります。また、十分なRAMがあります。VMは合計6 GBを使用し、ホストには10​​ GBが残っています。スワップ領域が0なので、スワップによって速度が低下することはありません。

btrfsはファイルシステムレベルでファイルの断片化を引き起こすため、仮想マシンの動作が遅くなる可能性があるという報告があります。ただし、私が知る限り、断片化は従来のハードディスクの問題にすぎません。SSDにはシークする読み取りヘッドがないため、ファイルが高度に断片化されているかどうかは関係ありません。

これは、Debian 7を実行しているときに発生することはなかったので、ハードウェアの問題ではないと確信しています。

システムがフリーズし続ける理由を理解するために、どのツールを実行できますか?私はtop / htopとiotopを試しました(システムがフリーズしたときに過度に書き込みや読み取りを行っているものはありません)。何かを読み書きするのに問題があるかどうかを確認するためのbtrfsのアクティビティモニターはないようです。他に試すことができるものはありますか?


これは、LUKSに関連付けられた使用に関連するかもしれない:unix.stackexchange.com/questions/203677/...
brauliobo

回答:


15

btrfs gotchasページから

ランダムな書き込みが多いファイルは、断片化が激しくなり(10000以上のエクステント)、HDDでトラッシュが発生したり、SSDまたは大容量のRAMを搭載したシステムでCPU負荷が数秒間急増したりする可能性があります。

  • サーバーとワークステーションでは、これはデータベースと仮想マシンイメージに影響します。

    • nodatacowマウントオプションは、関連する落とし穴とともにここで使用できます。

    ...

  • 症状には、btrfs-transactiとbtrfs-endio-wriが大量のCPU時間を消費する(スパイクで、同期によってトリガーされる可能性があります)が含まれます。filefragを使用して、非常に断片化されたファイルを見つけることができます(圧縮では正しく機能しない場合があります)。

Virtualboxで説明したのと同じような問題がありました。nodatacowbtrfs のオプションは、私のシステムでは目立った方法で役に立ちませんでした。自動最適化オプション(デスクトップ環境でのアプリケーションデータベースの可能な解決策として言及されています)も試してみましたが、動作を許容できるような結果にはなりませんでした。

最後に、btrfsパーティションとそれが存在する論理ボリュームを縮小し、新しいLVを作成してそれをext4としてフォーマットし、所有しているVMディスクイメージ(VirtualBox)をその「パーティション」に配置しました。


間違いなく私の問題のように聞こえます。実際にファイルがどのように断片化されているかを確認する方法を探していましたが、断片化を読み取​​ってもあきらめてもHDDのようにSSDには影響しません。どうやら私が読んだ場所は完全に正確ではなかったようです-それはSSDに影響を与えます-それは非常に興味深いです。filefragを試して、btrfsパーティションのサイズを変更し、VMをext4パーティションに移動して、レポートを作成します。ありがとう
Tal

0

これは透過的なヒュージページの問題である可能性があり、カーネルスレッドkhugepagedが文字通りRAMをマイニングしてデフラグしたり、4kからhugepagesを作成したりしています。

カーネルは、かなりの量のシステムRAMが与えられた場合にhugepagesを有効にすることを決定した可能性があります。

次の2つのカーネル調整パラメータの内容を確認してください。

/sys/kernel/mm/transparent_hugepage/enabled
/sys/kernel/mm/transparent_hugepage/defrag

それらのコンテンツがalwaysである場合、で変更しnever、CPUスパイク/フリーズが消えるかどうかを確認できます。


問題は書き込み遅延にあり、CPU使用率とは関係ありません
brauliobo

0

この問題は、パーティションでLUKSを使用しないことで完全に解決されました。そこで、最初にLUKSではなくBTRFSでパーティションを直接フォーマットしました。

また、次のパラメーターでマウントされます。

/dev/sda2 /           btrfs       rw,noatime,space_cache,compress=lzo,ssd,discard,autodefrag,commit=0,thread_pool=8 0 0

関連した非常に悪い一般的なDM-のcrypt(LUKS)書き込み性能

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.