Escalada de uso da CPU do host VMware

2

Isso é um pouco difícil, mas estou me perguntando se alguém poderia explicar o seguinte:

Eu tenho um VMware Host Server executando o Ubuntu Server 8.04 LTS e o VMware Server 2.0. O uso da CPU do usuário no host continua subindo, até eu reiniciar o servidor quando ele volta para quase nada - e começa a subir novamente. Isso ocorre desde que eu troquei uma VM do Server 2003 por uma do Server 2008 (atualizei meu controlador de domínio e migrei para 2008). Não consigo encontrar nenhum problema com o servidor Windows, ou qualquer uso anormalmente alto da CPU na própria VM.

Eu tenho me mantido atualizado sobre o host, então passei por cerca de 3 atualizações de kernel, várias recompilações de VMware e uma versão totalmente nova do VMware Server quando a última foi lançada não muito tempo atrás. Eu simplesmente não consigo descobrir isso.

Qualquer sugestão seria muito bem apreciada, agora estou apenas procurando coisas para experimentar!

    
por Rob Golding 14.08.2009 / 23:21

3 respostas

1

Eu não posso responder a pergunta, mas posso adicionar um pouco mais de evidência anedótica. Eu notei isso também, com um host Linux (Debian / Etch e Debian / Lenny).

Depois de algumas reclamações quando percebi a questão pela primeira vez, cheguei à conclusão de que a questão é VMWare, e não os próprios convidados. Ao parar todos os serviços nas VMs em uma máquina específica, o uso da CPU permaneceu alto, apesar dos sistemas operacionais nas VMs não fazerem nada. Ao desligar cada uma das quatro VMs, o uso excessivo da CPU do host caiu em cerca de 25% por VM (não medi isso por nenhum meio científico, mas certamente nenhuma VM parece estar impondo a maior parte da carga). Depois de restringir as VMs, o uso da CPU permaneceu onde costumava estar, mesmo com os serviços nas VMs ativos, e a carga começou a aumentar lentamente com o tempo, sem aumento relacionado na atividade útil aparente.

Em ambos os casos que eu notei isso acontecer, o sistema operacional host tem sido o Linux de 32 bits e os sistemas operacionais convidados também são Linux de 32 bits.

Ainda não o vi em todos casos. No meu servidor doméstico (kernel Linux de 64 bits com 32 bits de usuário executando um grande e dois pequenos Linux VMS de 32 bits e, ocasionalmente, Windows VMS para testes) eo principal servidor de desenvolvimento / teste no trabalho (Linux de 64 bits) kernel e userland) host executando principalmente Windows VMs, alguns de 32 bits e alguns 64) esse comportamento aberrante não parece estar presente. Todos os itens acima estão executando o VMWare Server 2.

Então, para encurtar a história: não é só você, e não são apenas convidados baseados no Windows, mas não parece ser um problema consistente (como muitos arranjos não vêem isso, , na minha experiência limitada). Embora infelizmente eu não possa ajudar mais do que isso, já que não tive tempo de examinar o problema com mais detalhes.

    
por 15.08.2009 / 01:02
1

Primeiro, já vi isso com o VMware Server também - no Windows e no Linux. Na minha experiência, isso estava relacionado à execução de ambas VMs de 64 e 32 bits ao mesmo tempo.

Embora possa não ser uma opção para você, sugiro o ESXi - a edição leve e gratuita do ESX.

    
por 15.08.2009 / 01:50
0

Eu tenho o mesmo problema em um servidor de produção. O sistema operacional host é o Debian Linux de 64 bits. Os hóspedes são 4 máquinas Linux e 1 Windows XP. Todos os hóspedes são de 32 bits. Quando reinicio todos os serviços VM no host, o agendamento da CPU é bom e a CPU do host por VM está no mesmo nível da atividade real do convidado. No entanto, após algumas semanas, o agendamento da CPU aumenta até que mais ou menos o tempo máximo disponível da CPU seja consumido nas VMs em execução. O uso da CPU no host nesse momento é mais ou menos 10x o uso inicial da CPU no momento em que as VMs começaram.

Para mim, parece um vazamento no agendamento da CPU no host. Instaed de vazamento de RAM, está vazando ciclos de CPU :-). Como tenho certeza de que isso não acontece no ESXi?

Thomasgg

    
por 24.06.2010 / 11:00