kcompacd0은 VMware Workstation 16에서 CPU를 100% 사용합니다.

kcompacd0은 VMware Workstation 16에서 CPU를 100% 사용합니다.

Redhat Bugzilla에 게시된 내용과 동일합니다.kcompacd0은 CPU를 100% 사용합니다., 마감시간은 입니다 INSUFFICIENT_DATA.

또한

거기에 있는 솔루션이 나에게 효과가 없었기 때문에 다시 엽니다.

내 상황은 다음과 같습니다.

  • 우분투21.10호스트 및 Windows10VMware Workstation 16 v를 사용하는 엔터프라이즈 클라이언트16.2.0빌드-18760230
  • 저는 화려하거나 로드가 많은 작업을 하지 않았는데, Windows 10(경부하)을 정기적으로 사용한 지 하루 만에 상황이 이상해지기 시작했습니다.
  • 프로세스는 하나의 코어에서 100% CPU를 사용하고 8개의 코어에서 100% CPU를 kcompactd0지속적으로 사용합니다 .vmware-vmx여기에 이미지 설명을 입력하세요.
  • 이런 일이 발생하면 일반적으로 몇 분 동안 지속됩니다. 그런 다음 1~2분 후에 다시 시작됩니다.
  • "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 오류 보고서 "khugpaged가 CPU를 100% 차지합니다". 버그는 수정되지 않았으며 "솔루션"은 2013년 Fedora 17에 대한 것이었고

지난 3개, 아마도 4-5개의 Fedora 커널 버전에서는 이 문제가 다시 발생하지 않았습니다.

하지만 이제 그런 일이 다시 일어났습니다.

답변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 게스트). 이는 게스트 컴퓨터에 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

적용하려면 다시 시작하세요.

~을 위한시스템 부팅, (a) 위 문자열을 별도의 줄에 추가 /etc/kernel/cmdline하거나 (b) 시작 항목.conf 파일에 다음 키를 추가합니다 /loader/entries.

options intel_iommu=on

파일을 저장하고 닫은 다음 다시 시작하면 적용됩니다.

편집하다

이 질문은 부분적으로 IOMMU 질문이지만 몇 가지 추가 정보가 나타났습니다.

  • 위와 같이 IOMMU를 구성하면 많은 도움이 되지만 결정적이지는 않습니다. 문제가 다시 발생합니다.
  • 당연히 이 질문은 Windows 게스트의 메모리 관리와 Linux 호스트의 메모리 관리 간의 상호 작용과 관련이 있습니다. 특히 애플리케이션의 Superfetch 기능을 비활성화(실행하지는 않음)하도록 Windows 게스트를 구성하면 많은 도움이 됩니다. Superfetch는 실행 시 필요하다고 생각되는 항목을 미리 로드하므로 나중에 더 빠르게 로드됩니다. 이 모든 것이 RAM으로 들어가 가상 머신의 RAM 소비를 늘리고 복구 및 압축을 위한 공간을 줄입니다. 이 기능을 끄면 주문형 로드 및 언로드가 가능합니다.
  • 또한 가상 머신 설정에서 VMware VM의 RAM 구성을 줄이는 것도 많은 도움이 될 수 있습니다. 처음에는 이것이 직관에 어긋나는 것처럼 보일 수 있지만 VMware Player는 처음부터 호스트 시스템에서 이 RAM을 모두 가져가므로 호스트에 재할당 및 압축을 위한 공간이 줄어듭니다. 16GB(16384MB) RAM이 설치된 시스템에서 VM RAM을 ~12GB에서 8192MB로 줄이면 실제로 문제가 해결되었습니다.
  • 그래도 문제는 몇 시간 사용 후에 발생할 가능성이 더 높으며,, 그날 늦게. 동결 기간은 훨씬 짧지만(분 대신 초) 일단 시작되면 동결된 상태를 유지합니다. 아마도 제거되어야 할 것이 호스트인지 게스트인지 확실하지 않습니다. 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의 기본 설정에서 찾을 수 있습니다. 아마도 동일한 설정 창에서 "예약된 메모리" 설정이 너무 높은 것과 관련이 있을 수 있습니다.

특히 지금은 다음을 사용하여 이러한 설정을 변경했습니다.일부 가상 머신 메모리 교환 허용, 이 문제가 해결되기를 바랍니다.

관련 정보