☰

kcompacd0 在 VMware Workstation 16 中使用 100% CPU

tag-icon • tag-icon vmware vmware-workstation
kcompacd0 在 VMware Workstation 16 中使用 100% CPU

与 redhat bugzilla 中发布的相同 --kcompacd0 使用 100% cpu，关闭时间为INSUFFICIENT_DATA。

也与

重新打开是因为那里的解决方案对我不起作用。

这是我的情况：

  • 乌班图21.10主机和Windows10企业客户端，配备 VMware Workstation 16 v16.2.0构建-18760230
  • 我没有做任何花哨或重负载的事情，就在常规使用 Windows 10（轻负载）一天之后，事情开始变得疯狂。
  • 该进程kcompactd0不断地在一个核心上使用 100% cpu，并vmware-vmx在八个核心上使用 100% cpu。 在此输入图像描述
  • 当发生这种情况时，通常会持续几分钟。然后一两分钟后再次启动。
  • “kcompactd0 仅随着 drop_caches 消失。当它达到 100% 时，vmware 虚拟机 guest 完全没有响应（windows 10 ltsc vm）”所以我只尝试了一次 drop_caches，并确认了该行为。

根据上游要求，以下是更多信息：

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 21.10
Release:        21.10
Codename:       impish


$ grep -r . /sys/kernel/mm/transparent_hugepage/*
/sys/kernel/mm/transparent_hugepage/defrag:always defer defer+madvise [madvise] never
/sys/kernel/mm/transparent_hugepage/enabled:always [madvise] never
/sys/kernel/mm/transparent_hugepage/hpage_pmd_size:2097152
/sys/kernel/mm/transparent_hugepage/khugepaged/defrag:1
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_shared:256
/sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs:10000
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none:511
/sys/kernel/mm/transparent_hugepage/khugepaged/pages_to_scan:4096
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_swap:64
/sys/kernel/mm/transparent_hugepage/khugepaged/alloc_sleep_millisecs:60000
/sys/kernel/mm/transparent_hugepage/khugepaged/pages_collapsed:0
/sys/kernel/mm/transparent_hugepage/khugepaged/full_scans:19
/sys/kernel/mm/transparent_hugepage/shmem_enabled:always within_size advise [never] deny force
/sys/kernel/mm/transparent_hugepage/use_zero_page:1

$ cat /proc/90/stack | wc
      0       0       0

echo never > /sys/kernel/mm/transparent_hugepage/defrag
echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag
echo never > /sys/kernel/mm/transparent_hugepage/enabled

$ grep -r . /sys/kernel/mm/transparent_hugepage/*
/sys/kernel/mm/transparent_hugepage/defrag:always defer defer+madvise madvise [never]
/sys/kernel/mm/transparent_hugepage/enabled:always madvise [never]
/sys/kernel/mm/transparent_hugepage/hpage_pmd_size:2097152
/sys/kernel/mm/transparent_hugepage/khugepaged/defrag:0
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_shared:256
/sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs:10000
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none:511
/sys/kernel/mm/transparent_hugepage/khugepaged/pages_to_scan:4096
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_swap:64
/sys/kernel/mm/transparent_hugepage/khugepaged/alloc_sleep_millisecs:60000
/sys/kernel/mm/transparent_hugepage/khugepaged/pages_collapsed:0
/sys/kernel/mm/transparent_hugepage/khugepaged/full_scans:19
/sys/kernel/mm/transparent_hugepage/shmem_enabled:always within_size advise [never] deny force
/sys/kernel/mm/transparent_hugepage/use_zero_page:1

基本上解决方法的来源是Fedora 错误报告“khugpaged 占用 100%CPU”。该错误从未得到修复，“解决方案”适用于 2013 年的 Fedora 17，并且

在过去 3 个，也许是 4-5 个版本的 Fedora Kernels 中，我没有再遇到这个问题。

但现在又发生了。

答案1

这是我在 Ubuntu 20.04 上的解决方案：

  1. 关闭虚拟机
  2. 使用文本编辑器打开 VM 的 <vm_name>.vmx 文件
  3. 将以下内容添加到 vmx 文件的末尾：
# Fix problem where vmware battles with kcompactd0.
vm.compaction_proactiveness=0
  1. 保存文件并重新启动VM

[更新 2022-03-06]：如果您升级到 VMware Workstation Pro 16.2.1，请确保在测试之前将虚拟机升级到 16.2 并重新启动计算机。升级后我没有重新启动，问题一直持续到重新启动。

[更新2022-11-28]：查看“加速3D图形”是否启用，如果不需要则禁用它。这可能是此问题的触发因素。

答案2

这实际上是一个 IOMMU 问题，解决方案包括在内核命令行启用它。在固件中启用 VT-d（Intel IOMMU 内核驱动程序）是不够的，修补compaction_proactiveness 和swappiness 只会限制这种行为，而无法解决根本原因。

我自己也遇到了这个问题（Ubuntu 22.04主机，内核版本5.15.0，VMware Player 16.2.4，Windows 10 guest）。当来宾计算机在 Firefox 中打开多个选项卡、打开数据库应用程序或两者兼而有之时，这种情况尤其明显。

值得注意的是，设置vm.compaction_proactiveness=0没有效果。设置vm.swappiness=10有一点帮助，但问题仍然存在。

尽管主机固件中启用了 VT-x 和 VT-d，但事实证明，至少在内核版本 5.15.0-46-default 中，内核是使用 intel_iommu 编译的，但默认情况下该配置是禁用的。因此，

cat /boot/config* | grep INTEL_IOMMU

返回（以及其他行）（注意 octothorpe 注释掉第二行）：

CONFIG_INTEL_IOMMU=y
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set

解决方案是将以下字符串添加到内核命令行中。这将启用 intel_iommu，修复来宾冻结，并防止kcompactd0将其 CPU 核心固定在 100%，至少到目前为止是这样：

intel_iommu=on

所以，对于GRUB，编辑/etc/default/grub以将上述字符串添加到GRUB_CMDLINE_LINUX_DEFAULT，例如,

GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on"

保存并关闭文件，然后运行：

# update-grub

重启即可生效。

为了systemd-boot，(a) 将上述字符串添加到单独的行中，/etc/kernel/cmdline或者 (b) 将以下密钥添加到启动条目 .conf 文件中/loader/entries：

options intel_iommu=on

保存并关闭文件，然后重新启动即可生效。

编辑

这个问题部分仍然是 IOMMU 问题，但出现了一些附加信息：

  • 如上所述配置 IOMMU 有很大帮助，但不是决定性的。问题再次出现。
  • 毫不奇怪，这个问题涉及 Windows 客户机的内存管理和 Linux 主机的内存管理之间的相互作用。具体来说，配置 Windows 来宾以禁用应用程序的 Superfetch 功能（但不启动）有很大帮助。 Superfetch 会预加载它认为您在启动时需要的内容，因此稍后加载速度会更快。所有这些都进入 RAM，增加了虚拟机的 RAM 消耗并减少了恢复和压缩的空间。关闭它允许按需加载和卸载。
  • 另外，在虚拟机设置中减少 VMware VM 的 RAM 配置也有很大帮助。乍一看这似乎有悖常理，但 VMware Player 从一开始就从主机系统中占用了所有这些 RAM，从而使主机没有太多空间用于重新分配和压缩。在安装了 16GB (16384MB) RAM 的系统上，将 VM RAM 从 ~12GB 减少到 8192MB 实际上消除了我的问题。
  • 尽管如此，该问题更有可能在使用几个小时后出现，IE，当天晚些时候。冻结持续时间要短得多（几秒钟，而不是几分钟），但一旦开始，它就会一直冻结。据推测，应该卸载的东西没有卸载，无论是主机还是客户机，目前尚不清楚。完全关闭客户机（而不是重新启动，这会让 VMware Player 及其 RAM 抢占运行）可以是一种有效的重置。有时，主机重新启动也是必要的。
  • Firefox 可以索取且不会放弃大量 RAM，至少在默认设置下是如此。这可以在其高级设置中进行一些配置。

敬请关注。

答案3

echo 0 > /proc/sys/vm/compaction_proactiveness

或者

sudo sh -c 'echo 0 > /proc/sys/vm/compaction_proactiveness'

来源：https://gist.github.com/2E0PGS/2560d054819843d1e6da76ae57378989

答案4

我在 Debian Linux 上的 VMware Workstation 17 和 17.5 中遇到了同样的问题。

我想知道这个问题是否与使用设置有关将所有虚拟机内存装入保留的主机 RAM，可以在 VMware GUI 的首选项中找到。也许与同一设置窗格中的“保留内存”设置过高有关。

我已经更改了这些设置，尤其是现在使用允许交换一些虚拟机内存，希望能解决这个问题。

相关内容