O Arch Linux deixa de responder a partir do khugepaged

Eu sou um usuário pesado da estação de trabalho VMware 10.0.3 e, como tal, tenho 32 GB de RAM no meu sistema. Meu único sistema operacional é o Arch Linux, usando o Unity para a área de trabalho.

Normalmente, quando tenho duas máquinas virtuais em execução com cerca de 3 GB de RAM designadas para cada uma, com muita frequência e em intervalos aleatórios, todo o sistema fica sem resposta por alguns segundos.

Executando "top" em um terminal, o culpado parece ser o comando khugepaged, que é executado enquanto o sistema não responde com 100% da CPU e desaparece.

Existe alguma maneira de evitar isso? Pesquisei no google sobre o khugepaged, mas só acho que encontrei postagens antigas de 2011 ou perguntas sem resposta.

Estas são minhas especificações completas do sistema:

Processador: Intel i5 4570@3.2GHz
Memória RAM Corsair Vengeance de 32 GB @ 2400 MHz
M / B ASrock Z87 Pro 4

arch-linux vmware

— Angelos Kyritsis
fonte

Como são suas configurações de troca? Esse tipo de interrupção geralmente está relacionado ao uso da troca. Você pode verificar a troca na próxima vez que travar? Ele só trava ao trocar ativamente?

— terdon

Por que deveria trocar com 32 GB de RAM? Nem chega a esgotar a RAM física. Eu tenho uma pequena partição de swap de 1 GB - já que está em um SSD e não queria desperdiçar imóveis. Não mudei a swappiness, acho que é o valor padrão.

— Angelos Kyritsis

Bem, o arch tem o padrão definido como 60, o que significa que ele começará a trocar muito antes que a RAM se esgote. Não estou dizendo que é troca com certeza, mas parece provável. Tente definir um valor mais baixo.

— terdon

Ok, eu configurei para 5. Informarei se isso fez alguma diferença.

— Angelos Kyritsis

unix.stackexchange.com/questions/161858/…

— mazgalici 5/15

Respostas:

Eu tenho um problema semelhante no Ubuntu. A solução alternativa que eu uso é:

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

A fonte da solução alternativa está em um relatório de bug do Fedora, “khugepaged eating 100% CPU” . O bug nunca foi corrigido.

Isso é menos drástico do que desativar todo o transparent_hugepagesuporte. A explicação detalhada do que o comando faz pode ser encontrada na documentação do suporte transparente a enormes páginas .

— Pawel Jasinski
fonte

echo never | sudo tee /sys/kernel/mm/transparent_hugepage/defrag; echo 0 | sudo tee /sys/kernel/mm/transparent_hugepage/khugepaged/defrag

— Treviño 29/11

@ Treviño, posso perguntar qual é a diferença para o que o autor da resposta está propondo: por que alguém deveria usar | sudo teeem vez disso >?

— Joma

@ Joma o sudo echo $value > outputnão funciona no Ubuntu, você precisa usar o teetruque, ou fazê-lo a partir do sudo -sshell.

— Treviño

Sério, eu amo você por isso, @ pawel-jasinski - a primeira vez em cinco anos que posso realmente trabalhar com o VMware sem que ele congele regularmente o SO host e o convidado.

— Simon A. Eugster

@ Joma O primeiro comando deve ser executado a partir de um shell raiz. Com sudo echo X > Y, apenas echo Xé executado como root, mas > Y(a saída direta para um arquivo) não é.

— Simon A. Eugster

khugepaged pode ser o problema, tente o seguinte:

echo never > /sys/kernel/mm/transparent_hugepage/enabled

isso me ajudou a resolver esse problema no arch linux recente ...

— ArchUser
fonte

Olá e bem-vindo ao site! Esperamos que as respostas sejam um pouco mais detalhadas aqui. Você poderia talvez editar sua resposta e explicar o que o comando que você sugere faz e como isso ajudaria?

— terdon

@ArchUser também, se você não tiver certeza de que esta é a solução, poste como comentário.

— precisa saber é o seguinte