Já faz algum tempo que venho tentando descobrir por que alguns de nossos sistemas críticos para os negócios estão recebendo relatórios de "lentidão" que variam de leve a extrema. Recentemente, voltei minha atenção para o ambiente VMware onde todos os servidores em questão estão hospedados.
Recentemente baixei e instalei a versão de avaliação do pacote de gerenciamento Veeam VMware para SCOM 2012, mas estou tendo dificuldade em acreditar (e meu chefe também) nos números que ele está me reportando. Para tentar convencer meu chefe de que os números que ele me diz são verdadeiros, comecei a pesquisar o próprio cliente VMware para verificar os resultados.
eu olheieste artigo da base de conhecimento da VMware; especificamente para a definição de Co-Stop que é definido como:
Quantidade de tempo que uma máquina virtual MP esteve pronta para execução, mas sofreu atraso devido à contenção de agendamento co-vCPU
Para o qual estou traduzindo
O sistema operacional convidado precisa de tempo do host, mas precisa esperar que os recursos fiquem disponíveis e, portanto, pode ser considerado "sem resposta"
Esta tradução parece correta?
Nesse caso, é aqui que tenho dificuldade em acreditar no que estou vendo: o host que contém a maioria das VMs "lentas" está atualmente mostrando uma média de Co-stop de CPU de127.835,94milissegundos!
Isso significa que, em média, as VMs neste host precisam esperar mais de 2 minutos pelo tempo de CPU???
Este host possui duas CPUs de 4 núcleos e possui CPU convidada de 1x8 e CPU convidada de 14x4.
Responder1
Posso descrever algumas das experiências que tive nesta área...
Não acredito que a VMware faça um trabalho adequado na educação dos clientes (ou administradores) sobre as melhores práticas, nem atualizam as práticas recomendadas anteriores à medida que os seus produtos evoluem. Esta questão é um exemplo de como um conceito central como a alocação de vCPU não é totalmente compreendido. A melhor abordagem é começar aos poucos, com uma única vCPU, até determinar que a VM exige mais.
Para o OP, o servidor host ESXi possui duas CPUs quad-core, produzindo 8 núcleos físicos.
O layout da máquina virtual descrito tem um total de 15 convidados; Sistemas 1 x 8 vCPU e 14 x 4 vCPU. Isso é muito comprometido, especialmente com a existência de umúnico convidado com 8 vCPUs. Isso não faz sentido. Se você precisa de uma VM tão grande, provavelmente precisará de um servidor maior.
Por favor, tentetamanho certosuas máquinas virtuais. Tenho certeza de que a maioria deles pode conviver com 2 vCPU. Adicionar CPUs virtuais não torna as coisas mais rápidas; portanto, se isso for uma solução para um problema de desempenho, é a abordagem errada a ser adotada.
Na maioria dos ambientes, a RAM é o recurso mais restrito. Mas a CPU pode ser um problema se houver muita contenção. Você tem evidências disso. RAM também pode ser um problema semuito é alocado para VMs individuais.
É possível monitorar isso. A métrica que você está procurando é "CPU Ready%". Você pode acessar isso no cliente vSphere selecionando uma VM e acessando Performance> Overview> CPU Graph.
- Menos de 5% de CPU pronta- Você está bem.
- 5-10% de CPU pronta- Acompanhe atentamente a atividade.
- Mais de 10% de CPU pronta- Não é bom.
Observe a linha amarela no gráfico abaixo.
Você se importaria de verificar isso em suas máquinas virtuais com problemas e reportá-las?
Responder2
Você afirma nos comentários que tem um host ESXi dual quad-core e está executando uma VM de 8vCPU equatorzeVMs de 4vCPU.
Se este fosse o meu ambiente, eu consideraria que eragrosseiramentesuperprovisionado. Eu colocaria no máximo quatro a seis convidados de 4vCPU nesse hardware. (Isso pressupõe que as VMs em questão tenham carga que exige que tenham uma contagem de vCPU tão alta.)
Presumo que você não conheça a regra de ouro... com o VMware você nunca deve atribuir a uma VM mais núcleos do que o necessário. Razão? O VMware usa um co-agendamento um tanto estrito que torna difícil para as VMs obterem tempo de CPU, a menos que haja tantos núcleos disponíveis quanto a VM atribuída. Ou seja, uma VM 4vCPU não pode executar 1 unidade de trabalho a menos que haja 4 núcleos físicos abertos ao mesmo tempo. Em outras palavras, é arquitetonicamente melhor ter uma VM de 1vCPU com 90% de carga de CPU do que uma VM de 2vCPU com 45% de carga por núcleo.
Então... SEMPRE crie VMs com um mínimo de vCPUs e adicione-as apenas quando for determinado que é necessário.
Para a sua situação, use a Veeam para monitorar o uso da CPU dos seus convidados. Reduza a contagem de vCPUs ao máximo possível. Eu estaria disposto a apostar que você poderia cair para 2vCPU em quase todos os seus convidados de 4vCPU existentes.
É verdade que se todas essas VMs realmente tiverem carga de CPU para exigir a contagem de vCPU que possuem, você simplesmente precisará comprar hardware adicional.
Responder3
Os 127.835,94 milissegundos são um somatório e você precisa dividir pelo tempo de amostragem para obter os valores% RDY corretos. Parece que você já está obtendo as leituras corretas de% RDY agora. Você pode aumentar bastante a proporção de vCPU para CPU física, mas não da maneira que está fazendo.
Você tem muitas VMs quádruplas com vCPU e até uma VM com 8 vCPU. Existem algumas respostas de qualidade já discutindo o dimensionamento correto e algumas ramificações da não consolidação dos ciclos para menos vCPUs. A única coisa que eu queria esclarecer é que, embora não seja mais o caso de uma VM precisar esperar que o número de CPUs físicas igual ao seu número de vCPUs fique disponível antes que qualquer instrução possa ser processada, é muito prejudicial ter um provisionamento excessivo dessa magnitude com a proporção de VMs multi-vCPU para núcleos físicos. 64 vCPUs em 8 núcleos está muito além da proporção máxima de 4 para 1. Presumo que você tenha HT nesses processadores, então você tem 16 núcleos lógicos? Isso pode ser aceitável com VMs de 1 e 2 vCPU com carga leve, mas se você tiver uma carga pesada nas VMs, será difícil de realizar.
Para sua informação, os processadores HT não são usados nos cálculos de% de CPU usada - ou seja, se você tiver 32 núcleos lógicos rodando a 2,4 Ghz em um servidor, estará com 100% de uso quando atingir 38,4 GHz. Então, quando você vê as médias de carga mostrando mais de 1,0, é por isso.
Aqui está um host ESXi que está executando uma proporção de 3,5 para 1 vCPU para CPU física (incluindo núcleos HT) com uma% RDY média de 3%.
11:13:49pm up 125 days 7:20, 1322 worlds, 110 VMs, 110 vCPUs; CPU load average: 1.34, 1.43, 1.37
%USED %RUN %SYS %WAIT %VMWAIT %RDY %IDLE %OVRLP %CSTP %MLMTD %SWPWT
13.51 15.87 0.50 580.17 0.03 4.67 66.47 0.29 0.00 0.00 0.00
15.24 18.64 0.43 491.54 0.04 4.65 63.70 0.43 0.00 0.00 0.00
13.44 16.40 0.44 494.10 0.02 4.33 66.24 0.48 0.00 0.00 0.00
13.75 16.30 0.51 494.26 0.32 4.32 66.06 0.35 0.00 0.00 0.00
17.56 20.72 0.58 489.35 0.04 4.31 60.76 0.45 0.00 0.00 0.00
13.82 16.43 0.50 494.12 0.07 4.31 66.26 0.26 0.00 0.00 0.00
13.65 16.81 0.49 493.81 0.03 4.21 65.93 0.37 0.00 0.00 0.00
13.73 16.51 0.42 493.63 0.09 4.06 66.24 0.29 0.00 0.00 0.00
13.89 16.37 0.55 580.61 0.04 3.95 66.69 0.28 0.00 0.00 0.00
14.02 17.00 0.33 494.11 0.03 3.93 66.10 0.29 0.00 0.00 0.00
13.44 15.84 0.49 495.17 0.04 3.87 67.24 0.27 0.00 0.00 0.00
13.59 15.84 0.50 580.27 0.04 3.81 67.24 0.44 0.00 0.00 0.00
17.10 19.86 0.50 490.97 0.04 3.74 62.21 0.39 0.00 0.00 0.00
13.32 15.77 0.50 495.34 0.03 3.73 67.47 0.27 0.00 0.00 0.00
13.43 16.15 0.48 494.95 0.05 3.72 67.09 0.38 0.00 0.00 0.00
13.44 16.47 0.49 580.88 0.04 3.72 66.81 0.40 0.00 0.00 0.00
13.71 17.00 0.29 494.13 0.03 3.71 66.26 0.37 0.00 0.00 0.00
17.34 20.41 0.39 490.50 0.05 3.70 61.70 0.37 0.00 0.00 0.00
13.42 16.19 0.50 495.07 0.03 3.66 67.15 0.38 0.00 0.00 0.00
13.56 16.23 0.48 494.97 0.03 3.60 67.12 0.30 0.00 0.00 0.00
14.95 17.53 0.42 578.82 0.09 3.57 65.72 0.35 0.00 0.00 0.00
13.44 16.07 0.56 581.14 0.04 3.54 67.34 0.40 0.00 0.00 0.00
17.19 21.27 0.37 575.41 0.04 3.44 61.08 0.51 0.00 0.00 0.00
13.57 16.99 0.30 580.64 0.01 3.37 66.69 0.38 0.00 0.00 0.00
13.79 16.25 0.43 495.25 0.04 3.35 67.39 0.39 0.00 0.00 0.00
11.90 14.67 0.30 496.86 0.02 3.31 69.00 0.36 0.00 0.00 0.00
17.13 19.28 0.56 491.83 0.03 3.30 63.26 0.48 0.00 0.00 0.00
14.01 16.17 0.50 495.56 0.01 3.30 67.66 0.39 0.00 0.00 0.00
16.86 20.16 0.57 491.19 0.05 3.20 62.44 0.43 0.00 0.00 0.00
14.94 17.46 0.42 580.05 0.08 3.16 66.24 0.40 0.00 0.00 0.00
14.56 16.94 0.36 494.86 0.08 3.14 66.91 0.42 0.00 0.00 0.00
......
Responder4
Desde então, instalamos o Veeam ONE, que esclareceu bastante onde estão nossos problemas de desempenho. Observando a tela CPU Bottlenecks no Veeam ONE e depois usandoSolução de problemas de uma máquina virtual que parou de responder: comparação de uso do VMM e da CPU convidadacomo referência, descobrimos onde está grande parte da nossa contenção "inaceitável".
Uma pequena dica que gostaria de compartilhar especificamente é que em um caso não consegui eliminar a contenção de CPU até remover o snapshot que estava na VM. Espero que isso ajude alguém.