Início / unix / Perguntas / 679706
Accepted
xpt
Asked: 2021-12-01 15:19:16 +0800 CST

kcompacd0 usando 100% da CPU com VMware Workstation 16

  • 772

Igual ao postado em redhat bugzilla -- kcompacd0 usando 100% cpu , que foi fechado para INSUFFICIENT_DATA.

Também igual a

Reabrindo porque a solução não funciona para mim.

Segue minha situação:

  • Host Ubuntu 21.10 e cliente Windows 10 Enterprise, com VMware Workstation 16 v 16.2.0 build-18760230
  • Não estou fazendo nada extravagante ou carga pesada, logo após um dia de uso regular do Windows 10 (de carga leve), as coisas começam a ficar loucas.
  • O processo kcompactd0está constantemente usando 100% de CPU em um núcleo e vmware-vmx100% de CPU em oito núcleos. insira a descrição da imagem aqui
  • Quando isso acontecer, normalmente durará vários minutos. Em seguida, entra em ação novamente após um ou dois minutos.
  • "kcompactd0 desaparece apenas com drop_caches. quando atinge 100%, o convidado da máquina virtual vmware não responde (windows 10 ltsc vm)" Então, tentei apenas drop_caches uma vez e confirmei o comportamento.

Conforme solicitado a montante, aqui estão mais informações:

$ 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

Basicamente, a fonte da solução alternativa está em um relatório de bug do Fedora “khugepaged comendo 100% da CPU” . O bug nunca foi corrigido, e a "solução" foi feita para o Fedora 17 no ano de 2013, e

com as últimas 3, talvez 4-5 versões do Fedora Kernels, não encontrei esse problema novamente.

Mas está acontecendo de novo agora.

vmware vmware-workstation

4 respostas

  1. echo 0 > /proc/sys/vm/compaction_proactiveness

    ou

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

    Fonte: https://gist.github.com/2E0PGS/2560d054819843d1e6da76ae57378989

    • 4

  2. Esta é a solução para mim no Ubuntu 20.04:

    1. Desligue a VM
    2. Abra o arquivo <vm_name>.vmx para a VM usando um editor de texto
    3. Adicione o seguinte ao final do arquivo vmx:
    # Fix problem where vmware battles with kcompactd0.
vm.compaction_proactiveness=0
    1. Salve o arquivo e reinicie a VM

    [Atualização 2022-03-06]: Se você atualizar para VMware Workstation Pro 16.2.1, certifique-se de atualizar suas VMs para 16.2 e reinicializar sua máquina antes de testar. Não reiniciei após a atualização e o problema persistiu até a reinicialização.

    • 2

  3. Não é uma "solução" em si, mas é uma solução para mim :

    ...Acho que o comportamento e a capacidade de resposta são muito, muito lentos e demonstram regularmente uma falta de resposta muito irregular . Ao executar uma VM, todo o sistema operacional ficará sem resposta por 30 segundos a minutos de cada vez e, em seguida, recuperarei algum nível de controle por um tempo e, em seguida, o sistema reverterá para um estado sem resposta ... enxágue, lave, repita .. .

    Eu tentei desinstalar e reinstalar o software (VMware Workstation 16) várias vezes e isso não fez nenhuma diferença.

    Então... fiz um experimento... instalei o Oracle VirtualBox para ver como isso se comportaria.

    Bem... que diferença!!

    Eu tenho 2 VMs Windows 10 , cada uma com 8 GB ou RAM, e um servidor Windows 2008 , um sistema Windows XP e 3 VMs Ubuntu (todos os sistemas antigos são porque estou fazendo treinamento Kali / Metaspolit) e com TODOS eles rodando em ao mesmo tempo , todo o sistema operacional e cada uma das VMs zumbem sem nenhuma preocupação no mundo.

    O sistema está realmente se comportando da maneira que eu esperaria ao executar todas essas VMs. A conclusão aqui é que eu tenho lutado com um desempenho extremamente frustrante usando o VMware Workstation 16 por meses e meses e o VirtualBox está arrasando .

    Em geral, eu amo o VMware, tenho um cluster Raspberry Pi ESXi e um Intel NUC executando o ESXi, todos relatando em uma instância do vCenter, usamos VMware no trabalho, etc., etc. desempenho .

    • 1
  4. Best Answer

    Na verdade, isso é um problema do IOMMU e a solução envolve ativá-lo na linha de comando do kernel. Habilitar o VT-d (o driver do kernel Intel IOMMU) no firmware não é suficiente e mexer com compaction_proactiveness e swappiness apenas restringe esse comportamento sem abordar a causa subjacente.

    Eu mesmo encontrei o problema (host do Ubuntu 22.04, versão do kernel 5.15.0, VMware Player 16.2.4, convidado do Windows 10). Foi especialmente pronunciado quando a máquina convidada tinha várias guias abertas no Firefox, aplicativos de banco de dados abertos ou ambos.

    Notavelmente, a configuração vm.compaction_proactiveness=0não teve efeito. A configuração vm.swappiness=10ajudou um pouco, mas o problema persistiu.

    Apesar de VT-x e VT-d terem sido habilitados no firmware do host, acontece que, pelo menos com a versão 5.15.0-46-default do kernel, o kernel é compilado com intel_iommu mas a configuração está desabilitada por padrão. Desta forma,

    cat /boot/config* | grep INTEL_IOMMU

    retorna (entre outras linhas) (observe o octothorpe comentando a segunda linha):

    CONFIG_INTEL_IOMMU=y
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set

    A solução é adicionar a seguinte string à linha de comando do kernel. Isso habilita o intel_iommu, corrige os congelamentos do convidado e evita kcompactd0fixar o núcleo da CPU em 100%, pelo menos até agora:

    intel_iommu=on

    Então, para GRUB , edite /etc/default/grubpara adicionar a string acima a GRUB_CMDLINE_LINUX_DEFAULT, por exemplo ,

    GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on"

    Salve e feche o arquivo e execute:

    # update-grub

    Reinicie para entrar em vigor.

    Para systemd-boot , (a) adicione a string acima em uma linha separada /etc/kernel/cmdlineou (b) adicione a seguinte chave ao seu arquivo .conf de entrada de inicialização em /loader/entries:

    options intel_iommu=on

    Salve e feche o arquivo e, em seguida, reinicie para entrar em vigor.

    EDITAR

    Este assunto continua a ser um problema da IOMMU em parte, mas algumas informações adicionais surgiram:

    • Configurar o IOMMU como acima ajuda muito, mas não definitivamente. O problema se repete.
    • O problema não surpreendentemente envolve uma interação entre o gerenciamento de memória do convidado Windows e o gerenciamento de memória do host Linux. Especificamente, configurar o convidado do Windows para desabilitar sua função Superfetch para aplicativos (mas não inicializar) ajudou imensamente. O Superfetch pré-carrega coisas que você acha que você vai precisar na inicialização, então ele carregará mais rápido mais tarde. Tudo isso vai para a RAM, aumentando o consumo de RAM da VM e reduzindo o espaço livre para recuperação e compactação. Desativar isso permite carregar e descarregar sob demanda.
    • Separadamente, reduzir a configuração de RAM da VM VMware nas configurações da máquina virtual ajuda muito. Isso pode parecer contra-intuitivo no início, mas o VMware Player reivindica toda essa RAM do sistema host desde o início, deixando o host sem muito espaço para realocação e compactação. Reduzir a RAM da VM de ~ 12 GB para 8192 MB em um sistema com 16 GB (16384 MB) de RAM instalada praticamente eliminou o problema para mim.
    • Não obstante o exposto, é mais provável que o problema ocorra após várias horas de uso, ou seja , no final do dia. A duração dos congelamentos é muito menor (segundos, não minutos), mas uma vez iniciado, continua fazendo isso. Presumivelmente, as coisas não estão descarregando o que deveria, se com host ou convidado ainda não está claro. Um desligamento completo do convidado (não uma reinicialização, que deixa o VMware Player e sua preempção de RAM em execução) pode ser uma reinicialização efetiva. Ocasionalmente, uma reinicialização do host também é necessária.
    • O Firefox pode reivindicar e não abrir mão de grandes quantidades de RAM, pelo menos com as configurações padrão. Isso pode ser configurado um pouco em suas configurações avançadas.

    Fique ligado.

    • 1

relate perguntas