我如何找出冻结机器的原因？

我正在这台机器上运行Arch：

3.40GHz i7六核（4930K）

16GB DDR3 1600MHz RAM

Raid0中2xSamsung 840 EVO SSD（使用BTRFS raid）

当我在带有几个VM（2个或3个）的Arch上运行VMware时，为它们分别提供大约2-4个内核和每个2GB RAM，我的系统开始出现随机冻结。每隔几分钟，系统将冻结10到30秒，然后再次开始移动，直到30秒后冻结，直到我关闭VM。当系统死机时，鼠标仍然可以正常移动，但是应用程序在主机上停止响应-vmware不响应，firefox（也在主机上打开）也不响应，等等。

冻结发生时，如果我正在运行进程监视器，它的确显示了vmware最大化的几个核心，但是同时，还有其他未使用的核心。我还拥有足够多的RAM-虚拟机总共使用6GB，主机剩余10GB。我的交换空间为0，所以交换不会减慢任何速度。

有报道称，由于btrfs导致文件在文件系统级别上碎片化，虚拟机可能运行缓慢。据我所知，碎片只是传统硬盘上的一个问题-SSD没有读取所需的读取头，因此它们不在乎文件是否高度碎片化。

当我运行Debian 7时，这种情况从未发生过，所以我很确定这不是硬件问题。

我可以运行哪些工具来弄清楚为什么系统不断冻结？我尝试了top / htop和iotop（系统死机时，没有写或读过多的东西）。似乎没有任何类型的btrfs活动监视器可以告诉它是否在跟上写/读任何内容方面遇到问题。还有什么我可以尝试的吗？

从btrfs 陷阱页面：

大量随机写入的文件可能会变得碎片化（超过10000个范围），从而导致HDD报废，并在具有SSD或大量RAM的系统上出现过多的CPU峰值峰值。

• 在服务器和工作站上，这会影响数据库和虚拟机映像。

  • 在此可以使用nodatacow挂载选项以及相关的陷阱。

  ...

• 症状包括btrfs-transacti和btrfs-endio-wri占用大量CPU时间（峰值，可能由同步触发）。您可以使用filefrag来查找零散的文件（在压缩时可能无法正常工作）。

如您使用Virtualbox所述，我遇到了类似的问题。nodatacowbtrfs 的选项在我的系统上没有明显的帮助。我也尝试了自动碎片整理选项（作为桌面环境中的应用程序数据库的一种可能的解决方案），也没有使行为可接受的结果。

最后，我缩小了btrfs分区及其所在的逻辑卷，创建了一个新的LV并将其格式化为ext4，然后将我拥有的VM磁盘映像（VirtualBox）放在该“分区”上。

这可能是一个透明的大页面问题，其中内核线程khugepaged从字面上挖掘您的RAM以对其进行碎片整理或从4k的大页面中提取大页面。

鉴于您的系统RAM相当大，内核可能决定启用大页面。

检查以下两个内核可调参数的内容：

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

如果它们的内容是always，则可以在中进行更改never，然后查看CPU峰值/冻结是否消失。

通过不在分区上使用LUKS完全解决了该问题。所以我直接用BTRFS格式化了分区，而不是先用LUKS格式化了。

还安装了以下参数：

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

与Abysmal General dm-crypt（LUKS）的写入性能有关