Vamos falar de CPU Ready e porque ele é importante

Padrão

Eu sou um usuário assíduo do esxtop. Uns olham ele como uma ferramenta de monitoramento, mas na verdade o esxtop é para troubleshooting. Com o esxtop você consegue obter informações valiosíssimas para identificar problemas e oportunidades para melhorar a performance do seu ambiente virtual.

Atualmente estou trabalhando em um novo projeto e, como sempre costumo fazer antes de botar a mão na massa, faço uma análise minuciosa do ambiente VMware, desde a arquitetura, até a avaliação de boas práticas da VMware, além de análise de desempenho e otimização de disponibilidade.

Nas últimas semanas, venho notado um alto consumo de CPU dos hosts. O DRS vem sendo muito requisitado, migrando automaticamente as VMs o dia todo.

Resolvi averiguar a fundo.

Comecei a investigar a possibilidade de estar ocorrendo um overcommitment de CPU no ambiente. Usando o esxtop, uma das métricas utilizadas pra fazer esse diagnóstico é o CPU Ready.

Abra uma sessão SSH ao host e digite esxtop. Vai aparecer uma tela parecida com essa:

Olhe bem para a coluna “%RDY”.

O ideal é que esse valor esteja o mais próximo possível de 0.

A não ser que você tenha um limite de CPU estipulado na máquina virtual (que na imagem representa a VM com 1024.92 de CPU Ready), valores acima de 5 não são normais.

Já valores acima de 10 são críticos e podem causar perda de performance da VM.

Mas que diabos é CPU Ready e o que ele significa? Te explico.

O ambiente virtual trabalha de forma diferente dos servidores físicos, e o provisionamento errado de uma máquina virtual pode influenciar bastante no seu desempenho. O que eu quero dizer é que muitas VMs acabam sendo mensuradas de forma errada, isso é, são provisionadas com um quantidade enorme de vCPUs ou com recursos escassos.

Basicamente, CPU Ready significa a quantidade de tempo que uma VM estava pronta para ser executada em um processador físico.

Vamos fazer uma analogia pra ficar melhor de entender:

VM 1: Oi processador físico, eu sou a VM 1 e preciso processar algumas coisas. Eu tenho 16 vCPUs e estou pronta para que você me insira na sua fila de processamento.

Processador físico: Oi VM 1, desculpa, mas não vou conseguir te ajudar no momento. Não tenho 16 cores disponíveis para te processar pois estou atendendo outras VMs. Espera um pouquinho e depois você tenta de novo.

Isso significa que a VM 1 deverá esperar até que 16 cores físicos estejam disponíveis para poder ser processada.

É a partir daí que o CPU Ready é medido.

Isso é uma particularidade do ESXi. O hypervisor da VMware usa o mesmo scheduler desde a sua primeira versão, baseado nos antigos virtualizadores Unix. Os outros grandes hypervisors trabalham de forma diferente e permitem que as VMs acessem os recursos físicos de forma assíncrona. Não que assim seja melhor. São apenas… diferentes.

É por isso que valores altos de CPU Ready podem causar perda de desempenho das VMs e do próprio host, que poderia usar estes processadores para VMs que estivessem realmente precisando.

Vamos dar uma olhada no monitoramento de CPU via vSphere Client.

Abra o vSphere Client, clique no host e em Performance. Clique em Advanced e mude para CPU. Clique em “Chart Options…”. Quero trazer os dados de ontem até hoje, por isso cliquei em “Past day”.

Selecione “Stacked Graph (Per VM)”, clique em “All” para selecionar todas as VMs e selecione o contador “Ready”. Clique em Apply.

Como vocês podem ver, pelo vSphere Client, o CPU Ready é medido em milisegundos, ao contrário do esxtop, que é medido em porcentagem. Existe uma fórmula para fazer o cálculo de milisegundos para porcentagem e esse site faz automaticamente pra você.

É bem simples. Informe os dados disponíveis no vSphere Client e ele te dará o valor em porcentagem.

Mas e agora? Verifiquei que existem VMs em meu ambiente com valores altos de CPU Ready, o que devo fazer?

  • Reduza o número de vCPUs das máquinas virtuais.
  • Verifique se a aplicação trabalha com multi-threading. Não faz sentido uma aplicação single thread ter 16 vCPUs. A não ser que a aplicação se beneficie do SMP, sempre inicie as máquinas com apenas 1 vCPU.
  • Altere o “host power management” para “high performance”.
  • Tome as rédeas no provisionamento de máquinas virtuais. Uma das maiores vantagens da virtualização é a alocação dinâmica de recursos e a escalabilidade, portanto, comece pequeno e aumente conforme for necessário.
  • Utilize ferramentas de monitoramento de performance do ambiente, como o vRealize Operations Manager e o Turbonomic (antigo VMturbo). Essas ferramentas possuem inúmeros recursos para te auxiliar na administração do vSphere. Depois de algum tempo rodando no ambiente, você consegue diagnosticar o overcommitment através de relatórios que informam qual deveria ser o recurso correto baseado no histórico de consumo da VM, os chamados relatórios de rightsizing. Como a ferramenta detecta padrões do seu ambiente, é importante que ela esteja rodando já a algum tempo (3 meses no mínimo) para poder gerar relatórios confiáveis.

Existem outros fatores importantes a serem considerados, como o NUMA e o vNUMA. Esses dois exigem uma atenção especial e por isso vou tratar deles em um outro post.

Até mais!

Meu nome é Pedro Calixto e sou apaixonado por tecnologia. O intuito desse blog é compartilhar um pouco do meu conhecimento/experiência, com uma linguagem fácil e acessível para todo mundo.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *