Quanta contenção há em excesso no VMware?

Há algum tempo, 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 meus olhos para o ambiente VMware, onde todos os servidores em questão estão hospedados.

Recentemente, baixei e instalei a avaliação do pacote de gerenciamento Veeam VMware para o SCOM 2012, mas estou tendo dificuldade em acreditar (e meu chefe também) nos números que estão me reportando. Para tentar convencer meu chefe de que os números que estão dizendo são verdadeiros, comecei a procurar no próprio cliente VMware para verificar os resultados.

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

Tempo em que uma máquina virtual MP estava pronta para ser executada, mas ocorreu um atraso devido à contenção de agendamento da co-vCPU

Para o qual estou traduzindo

O sistema operacional convidado precisa de tempo do host, mas precisa aguardar a disponibilidade de recursos e, portanto, pode ser considerado "sem resposta"

Esta tradução parece correta?

Nesse caso, aqui é onde 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 de 127.835,94 milissegundos!

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

Este host possui duas CPUs de quatro núcleos e possui convidado de CPU 1x8 e convidados de CPU 14x4.

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

Não acredito que a VMware faça um trabalho adequado para educar os clientes ( ou administradores ) sobre as práticas recomendadas, nem atualize as práticas recomendadas anteriores à medida que seus produtos evoluem. Esta pergunta é 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 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 é de 15 convidados totais; 1 x 8 sistemas vCPU e 14 x 4 vCPU. Isso é muito comprometido demais, especialmente com a existência de um único convidado com 8 vCPUs . Isso não faz sentido. Se você precisar de uma VM tão grande, provavelmente precisará de um servidor maior.

Por favor, tente dimensionar corretamente suas máquinas virtuais. Tenho certeza de que a maioria deles pode viver com 2 vCPU. A adição de CPUs virtuais não torna as coisas mais rápidas, por isso, se isso é um remédio 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 disputa. Você tem evidência disso. A RAM também pode ser um problema se houver muita alocação para VMs individuais .

É possível monitorar isso. A métrica que você está procurando é "CPU Ready%". Você pode acessar este a partir do cliente vSphere, selecionando um VM e vai Performance> Overview> Gráfico CPU.

• Com menos de 5% de CPU pronta - você está bem.
• 5-10% de CPU pronto - observe 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 nas máquinas virtuais com problemas e enviar relatórios?

Você declara nos comentários que possui um host ESXi de núcleo quádruplo duplo e está executando uma VM de 8vCPU e quatorze VMs de 4vCPU.

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

Suponho 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 precisa. Razão? O VMware usa um co-agendamento rigoroso que dificulta o tempo de CPU das VMs, a menos que haja tantos núcleos disponíveis quanto a VM é atribuída. 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, uma VM de 2vCPU com 45% de carga por núcleo.

Portanto ... SEMPRE crie VMs com um mínimo de vCPUs e adicione-as somente quando for necessário.

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

Concedido, se todas essas VMs realmente tiverem a carga da CPU para exigir a contagem de vCPU que possuem, basta comprar hardware adicional.

Os 127.835,94 milissegundos são uma soma e é necessário dividir pelo tempo da amostra para obter os valores corretos de% RDY. Parece que você já está obtendo as leituras% RDY corretas agora. Você pode ir muito alto com a relação vCPU / CPU física, mas não da maneira que está fazendo isso.

Você tem muitas VMs quad vCPU e até uma VM de 8 vCPU. Já existem algumas respostas de qualidade que discutem o dimensionamento correto e algumas ramificações de não consolidação de ciclos para menos vCPUs. A única coisa que eu queria esclarecer é que, embora não seja mais o caso de uma VM esperar pelo número de CPUs físicas iguais ao número de vCPUs disponíveis antes que qualquer instrução possa ser processada, isso é muito prejudicial. ter excesso de provisionamento dessa magnitude com a proporção de VMs com várias vCPU para núcleos físicos. 64 vCPUs em 8 núcleos estão muito além da proporção máxima de 4 para 1. Presumo que você tenha HT nesses processadores para ter 16 núcleos lógicos? Isso pode ser bom com VMs de 1 e 2 vCPU com carga leve, mas se você tiver uma carga pesada nas VMs, seria difícil de executar.

FYI Os processadores HT não são usados ​​nos cálculos de% de CPU utilizados - ou seja, se você possui 32 núcleos lógicos em 2,4 Ghz em um servidor, está 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 taxa de 3,5 a 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

......

Desde então, instalamos o Veeam ONE, que esclareceu bastante onde estão nossos problemas de desempenho. Observando a tela Gargalos da CPU no Veeam ONE e usando Solucionando problemas de uma máquina virtual que parou de responder: Comparação de uso de CPU VMM e Guest como referência, descobrimos onde está a nossa contenção "inaceitável".

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