私はこのコンピュータでArchを実行しています。
3.40GHz i7 6コア(4930K)
16GB DDR3 1600MHzメモリ
Raid0のSamsung 840 EVO SSD 2個（BTRFS raidを使用）
それぞれ約2〜4個のコアと2 GBのRAMを備えたいくつかのVM（2つまたは3つ）を使用してArchでVMwareを実行すると、システムがランダムに停止し始めました。数分ごとにシステムが10〜30秒間停止し、再び動き始め、VMをシャットダウンするまで30秒後に再び停止します。システムが停止すると、マウスはまだ正常に移動しますが、ホストコンピュータのアプリケーションは応答を停止します。 vmwareが応答せず、Firefox（ホストコンピュータでも開いている）が応答しません。
停止が発生したときにプロセスモニタを実行すると、vmwareは複数のコアを使い果たしましたが、同時に使用していない他のコアがあることを示します。また、RAMが十分です。仮想マシンは合計6GBを使用し、ホストには10GBが残ります。私のスワップスペースはゼロなので、スワップは遅くなりません。
ファイルシステムレベルでは、btrfsによるファイルの断片化によって仮想マシンが遅く実行される可能性があるという報告があります。しかし、私が知っている限り、断片化は既存のハードドライブでのみ問題になります。 SSDには検索する読み取りヘッドがないため、ファイルがひどく断片化しても問題ありません。
Debian 7を実行すると、これは起こらなかったので、ハードウェアの問題ではないと確信しています。
システムが停止し続ける理由を特定するためにどのツールを実行できますか？私はtop / htopとiotopを試しました（システムが停止した場合は何も上書きまたは読み取られません）。 btrfsが書き込み/読み取りに問題があるかどうかを知らせるアクティビティモニタはないようです。私が試すことができる他のものがありますか？
答え1
btrfsからトラップページ:
ランダム書き込み回数の多いファイルは重大に断片化され（10000以上）、HDDが破損し、SSDまたは大容量RAMを搭載したシステムでCPU負荷が数秒間過度に急増する可能性があります。
サーバーとワークステーションでは、これはデータベースと仮想マシンのイメージに影響します。
- nodatacowインストールオプションはここで役に立ち、関連する問題があります。
...
- 症状には、btrfs-transactiとbtrfs-endio-wriが多くのCPU時間を占める（スパイク、同期によってトリガーされる可能性があります）などがあります。 filefragを使用すると、ひどく断片化されたファイル（圧縮時に正しく機能しない可能性があります）を見つけることができます。
Virtualboxで説明したのと同様の問題が発生しました。 btrfsオプションはnodatacow私のシステムにはあまり役に立ちません。また、自動デフラグオプション（デスクトップ環境のアプリケーションデータベースの可能な解決策と呼ばれています）を試しましたが、動作を可能にする結果は得られませんでした。
最後に、btrfsパーティションとそのパーティションがあった論理ボリュームを縮小し、新しいLVを作成してext4でフォーマットし、その「パーティション」にあったVMディスクイメージ（VirtualBox）を配置しました。
答え2
パーティションでLUKSを使用しないことで問題が完全に解決されました。そのため、まずLUKSを使用する代わりに、BTRFSを使用してパーティションを直接フォーマットしました。
以下のパラメーターもインストールされます。
/dev/sda2 / btrfs rw,noatime,space_cache,compress=lzo,ssd,discard,autodefrag,commit=0,thread_pool=8 0 0
答え3
これは、カーネルスレッドが発生する透明なhugepageの問題かもしれません。巨大なページング、文字通りRAMを採掘してデフラグを実行するか、4kページから巨大なページを作成します。
システムに大量のRAMがある場合、カーネルは大容量ページを有効にすることを決定できます。
次の2つのカーネルチューナブルの内容を確認してください。
/sys/kernel/mm/transparent_hugepage/enabled
/sys/kernel/mm/transparent_hugepage/defrag
内容がある場合は、always変更してneverCPUスパイク/ストップが消えるかどうかを確認できます。