Quanta contenção é demais no VMware?

Question

Por um tempo, agora estou tentando descobrir por que alguns dos nossos sistemas críticos de negócios estão recebendo relatórios de "lentidão" que variam de moderados a extremos. Recentemente, voltei a minha atenção para o ambiente VMware, onde todos os servidores em questão estão hospedados.

Recentemente, baixei e instalei o teste do pacote de gerenciamento Veeam VMware para o SCOM 2012, mas estou tendo dificuldades em acreditar (e também em meu chefe) os números que ele está reportando para mim. Para tentar convencer meu chefe de que os números que ele está me contando são verdadeiros, comecei a investigar o próprio cliente VMware para verificar os resultados.

Eu olhei para este artigo da VMware KB ; especificamente para a definição de Co-Stop, que é definida como:

Amount of time a MP virtual machine was ready to run, but incurred delay due to co-vCPU scheduling contention

Que estou traduzindo para

The guest OS needs time from the host but has to wait for resources to become available and therefore can be considered "unresponsive"

Esta tradução parece correta?

Se assim for, aqui é onde eu tenho dificuldade em acreditar no que estou vendo: O host que contém a maioria das VMs que estão "lentas" está mostrando uma média de CPU Co-stop de 127,835.94 milissegundos!

Isso significa que, em média, as VMs neste host precisam esperar 2 minutos ou mais pelo tempo de CPU?

Este host tem dois processadores de 4 núcleos e conta com convidados de CPU de 1x8 e 14x4 de CPU.

    

Answer 1

Eu posso descrever algumas das experiências que tive nesta área ...

Eu não acredito que a VMware faça um trabalho adequado de educar os clientes ( ou administradores ) sobre as práticas recomendadas, nem atualize as práticas recomendadas anteriores à medida que 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 pequeno, com uma única vCPU, até você determinar que a VM requer mais.

Para o OP, o servidor host ESXi tem dois processadores quad-core, gerando 8 núcleos físicos.

O layout da máquina virtual descrita é de 15 convidados no total; 1 x 8 sistemas de vCPU e 14 x 4 de vCPU. Isso é demais, especialmente com a existência de um convidado único 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, tente dimensionar corretamente suas máquinas virtuais. Eu tenho certeza que a maioria deles pode viver com 2 vCPU. Adicionar CPUs virtuais não faz com que as coisas funcionem mais rápido, então, se isso é um remédio para um problema de desempenho, é a abordagem errada a ser tomada.

Na maioria dos ambientes, a RAM é o recurso mais restrito. Mas a CPU pode ser um problema se houver muita disputa. Você tem provas disso. A RAM também pode ser um problema se muito é alocado para VMs individuais .

É possível monitorar isso. A métrica que você está procurando é "CPU Ready%". Você pode acessá-lo a partir do cliente vSphere selecionando uma VM e indo para Performance > Overview > Gráfico da CPU.

• Abaixo de 5% da CPU pronta - você está bem.
• 5-10% CPU Ready - Observe atentamente a atividade.
• Mais de 10% da CPU pronta - não é boa.

Observe a linha amarela no gráfico abaixo.

Você se importaria de verificar isso em suas máquinas virtuais com problemas e reportar de volta?

    

Answer 2

Você declara nos comentários que tem um host ESXi de quatro núcleos e está executando uma VM de 8vCPU e quatorze VMs de 4vCPU.

Se este fosse o meu ambiente, eu consideraria isso grosseiramente superprovisionado. Eu colocaria no máximo quatro a seis convidados 4vCPU nesse hardware. (Isso pressupõe que as VMs em questão tenham uma carga que exige que elas tenham essa alta de uma contagem de vCPUs.)

Estou assumindo que você não conhece a regra de ouro ... com o VMware, você nunca deve atribuir uma VM a mais núcleos do que precisa. Razão? O VMware usa um co-agendamento restrito que dificulta às VMs obter tempo de CPU, a menos que haja tantos núcleos disponíveis quanto a VM for designada. Ou seja, uma VM de 4vCPU não pode executar 1 unidade de trabalho, a menos que haja 4 núcleos físicos abertos no mesmo momento. Em outras palavras, é arquitetonicamente melhor ter uma VM de 1vCPU com 90% de carga da CPU e, em seguida, ter uma VM de 2vCPU com 45% de carga por núcleo.

Então ... SEMPRE crie VMs com um mínimo de vCPUs e só as adicione quando for determinado como necessário.

Para sua situação, use o Veeam para monitorar o uso da CPU em seus convidados. Reduza a contagem de vCPUs no maior número possível. Eu estaria disposto a apostar que você poderia cair para 2vCPU em quase todos os seus convidados 4vCPU existentes.

Se todas essas VMs tiverem a carga da CPU necessária para a contagem de vCPUs, basta comprar hardware adicional.

    

Answer 3

Os 127.835,94 milissegundos são um somatório e você precisa dividir pelo tempo de amostragem para obter os valores de% RDY corretos. Parece que você já está recebendo as leituras de% RDY corretas agora. Você pode ir bem alto com a taxa vCPU para a cpu física, mas não do jeito que você está fazendo.

Você tem muitas VMs de vCPU quádruplas e até mesmo uma VM de 8 vCPUs. Existem algumas respostas de qualidade que já discutem o dimensionamento correto e algumas ramificações de não consolidar os 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 seja igual ao número de vCPUs disponíveis antes que qualquer instrução possa ser processada, isso é muito prejudicial. ter superprovisionamento dessa magnitude com a proporção de VMs com várias vCPUs para núcleos físicos. 64 vCPUs em 8 núcleos estão muito além do máximo de 4 para 1. Eu suponho que você tem HT nesses processadores, então você tem 16 núcleos lógicos? Isso pode ser OK com 1 e 2 VMs de vCPU que têm carga leve, mas se você tiver uma carga pesada nas VMs, seria difícil de realizar.

FYI Os processadores HT não são usados nos cálculos usados% da CPU - o que significa que se você tem 32 núcleos lógicos rodando a 2,4 Ghz em um servidor, você está com 100% de uso quando atinge 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 CPU de 3,5 a 1 para a CPU física (incluindo núcleos HT) com uma média de RDY% 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

......

    

Answer 4

Desde então, instalamos o Veeam ONE, o que esclarece quais são nossos problemas de desempenho. Ao olhar para a tela de afunilamentos da CPU no Veeam ONE, use Solução de problemas de uma máquina virtual que parou de responder: Comparação do uso da CPU do VMM e Convidado como referência, descobrimos onde colocar nosso" inaceitável "contenção é.

Uma pequena dica que eu queria compartilhar especificamente é que, em um caso, não consegui eliminar a contenção de CPU até que eu removesse o instantâneo que estava na VM. Espero que isso ajude alguém.