kcompcd0 使用 100% CPU 和 VMware Workstation 16

與 redhat bugzilla 中發布的相同 - kcompcd0 using 100% cpu已關閉INSUFFICIENT_DATA。

也一樣

• Linux 主機上的 VMware 導致定期凍結
• Arch Linux 從 khugepaged 變得無響應

重新打開，因為那裡的解決方案對我不起作用。

這是我的情況：

• Ubuntu 21.10主機和 Windows 10 Enterprise 客戶端，帶有 VMware Workstation 16 v 16.2.0 build-18760230
• 我沒有做任何花哨或重負載的事情，就在正常使用 Windows 10 一天（輕負載）之後，事情開始變得瘋狂。
• 該過程kcompactd0不斷在一個核心上vmware-vmx使用 100% cpu，在八個核心上使用 100% cpu。
• 當它發生時，它通常會持續幾分鐘。然後在一兩分鐘後再次啟動。
• *“kcompactd0 僅與 drop_caches 一起消失。當它達到 100% 時，vmware 虛擬機來賓完全沒有響應（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 錯誤報告“khugepaged eating 100%CPU”。該錯誤從未被修復，“解決方案”是針對 2013 年的 Fedora 17 的，並且

對於最後 3 個，也許是 4-5 個 Fedora 核心版本，我再也沒有遇到過這個問題。

但現在又發生了。

這是我在 Ubuntu 20.04 上的解決方案：

1. 關閉虛擬機
2. 使用文本編輯器打開 VM 的 <vm_name>.vmx 文件
3. 將以下內容添加到 vmx 文件的末尾：

# Fix problem where vmware battles with kcompactd0.
vm.compaction_proactiveness=0

4. 保存文件並重啟虛擬機

$$ Update 2022-03-06 $$：如果您升級到 VMware Workstation Pro 16.2.1，請確保將您的虛擬機升級到 16.2 並在測試前重新啟動您的機器。升級後我沒有重新啟動，問題一直存在，直到重新啟動。

echo 0 > /proc/sys/vm/compaction_proactiveness

或者

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

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

引用自：https://unix.stackexchange.com/questions/679706