Possíveis razões para alta carga de CPU do processo taskmgr.exe na VM?

Question

Em uma máquina virtual VMware que apresenta problemas graves de desempenho, vejo uma média constante de mais de 20% da carga da CPU para o processo TASKMGR.EXE (gerenciador de tarefas). Os aplicativos executados neste servidor têm uma carga menor, em torno de 4 a 10% da média. A VM está executando o Windows 2003 Server Standard com 3,75 GB de RAM atribuída. Eu suspeito que a carga da CPU do gerenciador de tarefas tenha algo a ver com outras instâncias de VM no servidor VMWare, mas não consegui ver um valor semelhante em sistemas ESXi internos (a VM problemática é executada na TI de clientes).

    

Answer 1

Eu tive sintomas semelhantes, não em uma VM, mas em um laptop Win7. O Taskmgr.exe e outros processos (como o Winmerge.exe) estavam recebendo 13% do cpu (um de oito). O problema foi temporariamente aliviado pelo reinício, então eu estava fazendo muito isso.

Depois de muito tempo investigando, achei que o Webroot Secure Anywere (software para vírus e outros tipos de proteção) WRSA.exe era o culpado. Depois que terminei esse processo, tudo começou a ser rápido de novo como mágica! Ainda não tenho certeza do que usar em vez de Webroot para proteção.

    

Answer 2

Bem, e se você acabou de sair do gerenciador de tarefas? : -)

Toda vez que eu vi valores ridículos para o gerenciador de tarefas carregar, ele acabou se trocando no host da VM devido à falta de memória. Verifique suas estatísticas de memória no host, especialmente os valores de memória designada e usada e a troca usada.

    

Answer 3

O desempenho em um servidor de virtualização deve ser avaliado primeiro no servidor físico e, em seguida, nas VMs.

Dentro da VM, os cálculos de tempo não são precisos, especialmente se você comprometer os VCPUs.

Além disso, o tempo gasto na CPU na hora do sistema pode afetar muito o desempenho. Mesmo um 10% poderia dobrar o tempo de resposta de uma VM, mesmo se a CPU no total fosse inferior a 15% usada.

Verifique se você não está exagerando na memória e o servidor host não está trocando. Isso irá liberar seu desempenho até o dreno. Verifique se as ferramentas do VMware estão instaladas e se os drivers de paravirtualização (E / S direta, balão) estão sendo executados.

    

Answer 4

O Gerenciador de Tarefas tenta fazer as coisas em tempo real. É polling recursos em uma freqüência definida. Para qualquer conjunto de métricas e carga sendo monitorado pelo gerenciador de tarefas, o número de instruções é determinado por algum valor fixo pelo algoritmo em funcionamento.

Se estiver usando 20% de CPU para um determinado conjunto de métricas, é porque não há muito CPU para começar. Se você executar a mesma carga em uma máquina com 10X a CPU, ela ocupará apenas 2% da CPU.

A% de CPU usada é, portanto, relativa à CPU disponível. No caso de uma VM, é relativo à capacidade física da CPU sua execução em menos a capacidade da CPU consumida pelas outras VMs.

20% é apenas muito em relação ao total de CPU disponível para a VM, e só é importante se você tiver coisas melhores a fazer com essa CPU.

BTW - lembre-se de que você não deve se preocupar com o consumo de CPU, a menos que esteja sendo consumido e não esteja fazendo algo útil, ou não fazendo o suficiente, porque você tem mais coisas para fazer.

100% de consumo de CPU não é ruim, é desejável. Isso significa que, para uma determinada carga de trabalho, você está correndo o mais rápido possível. Monitore a fila da CPU, se esta for > 0, então você precisa de mais CPU.

Usando < 100% da CPU não é boa, especialmente quando você está tentando fazer o trabalho. Tenha em mente que a CPU é um recurso temporal. Ciclos não utilizados não podem ser armazenados e não têm valor, eles simplesmente representam oportunidades desperdiçadas para fazer as coisas.

Um sistema ideal mostra apenas CPU extra quando não está carregado.

    

Answer 5

Eu tive um problema parecido com uma VM padrão de 2003 no vSphere 5.1. Inicialmente eu tinha configurado uma VM muito simples (4GB vRAM, 20GB vDisk) com 1 socket com 2 núcleos. No modo inativo, a CPU da VM estava constantemente na faixa de 30 a 50%, apesar de não haver programas instalados & foi totalmente atualizado etc

Eu tentei diferentes configurações de CPU e quando mudei o número de vCores de 1 socket & 2 núcleos para 1 soquete e 4 núcleos, (e reiniciado), tudo se acalmou - ocioso em 99%.

Eu não sei o suficiente sobre a metodologia vCPU para oferecer uma explicação, mas talvez ajude alguém

o host em si é um DL385 Gen8 com AMDs de 2 x 16 núcleos.