Se você administra uma infraestrutura virtual baseada em VMware vSphere (ou qualquer outro conjunto de tecnologias), provavelmente ouve frequentemente reclamações dos usuários: "A máquina virtual está lenta!" Neste ciclo de artigos, vou abordar as métricas de desempenho e explicar o que e por que "está lento" e como evitar que isso aconteça.
Vou considerar os seguintes aspectos do desempenho das máquinas virtuais:
- CPU,
- RAM,
- DISCO,
- Rede.
Começarei com a CPU.
Para analisar o desempenho, precisaremos de:
- Contadores de Desempenho do vCenter – contadores de desempenho cujos gráficos podem ser visualizados através do vSphere Client. As informações desses contadores estão disponíveis em qualquer versão do cliente (cliente "gordo" em C#, cliente web em Flex e cliente web em HTML5). Neste artigo, utilizaremos capturas de tela do cliente em C#, apenas porque ficam melhores em miniatura:)
- ESXTOP – uma ferramenta que é executada a partir da linha de comando do ESXi. Com ela, é possível obter valores dos contadores de desempenho em tempo real ou exportar esses valores durante um período específico para um arquivo .csv para análise posterior. A seguir, falarei mais sobre essa ferramenta e fornecerei alguns links úteis para documentação e artigos sobre o tema.
Um pouco de teoria
No ESXi, cada vCPU (núcleo da máquina virtual) é controlado por um processo separado – world, na terminologia da VMware. Também existem processos auxiliares, mas, do ponto de vista da análise de desempenho da VM, eles são menos interessantes.
Um processo no ESXi pode estar em um dos quatro estados:
- Run – o processo está realizando algum trabalho útil.
- Aguardar – o processo não está realizando nenhum trabalho (inativo) ou está aguardando entrada/saída.
- Costop – uma condição que ocorre em máquinas virtuais de múltiplos núcleos. Ela surge quando o agendador de CPU do hiperconector (ESXi CPU Scheduler) não consegue programar a execução simultânea em núcleos físicos do servidor para todos os núcleos ativos da máquina virtual. No mundo físico, todos os núcleos do processador operam de forma paralela, e o sistema operacional convidado dentro da VM espera um comportamento semelhante, o que obriga o hiperconector a desacelerar os núcleos da VM que têm a capacidade de concluir um ciclo mais rapidamente. Nas versões modernas do ESXi, o agendador de CPU utiliza um mecanismo chamado co-agendamento relaxado: o hiperconector considera a diferença entre o núcleo da máquina virtual que é o mais “rápido” e o mais “lento” (skew). Se essa diferença ultrapassa um determinado limite, o núcleo “rápido” entra no estado costop. Se os núcleos da VM passam muito tempo nesse estado, isso pode causar problemas de desempenho.
- Pronto – o processo entra neste estado quando o hiperconector não consegue alocar recursos para a sua execução. Valores altos de ready podem causar problemas de desempenho na VM.
Principais contadores de desempenho de CPU da máquina virtual
Uso de CPU, %. Mostra a porcentagem de utilização da CPU durante um período determinado.
Como analisar? Se a VM utiliza a CPU de forma estável a 90% ou apresenta picos de até 100%, isso indica problemas. Os problemas podem se manifestar não somente com a lentidão do aplicativo dentro da VM, mas também com a indisponibilidade da VM na rede. Se o sistema de monitoramento mostra que a VM está desconectando periodicamente, preste atenção aos picos no gráfico de Uso de CPU.
Há um Alarme padrão que mostra a carga da CPU da máquina virtual:
O que fazer? Se a Utilização de CPU da VM está constantemente alta, considere aumentar o número de vCPUs (infelizmente, isso nem sempre ajuda) ou mover a VM para um servidor com processadores mais potentes.
Uso de CPU em Mhz
Nos gráficos de Uso no vCenter em %, é possível visualizar apenas para toda a máquina virtual, não há gráficos para núcleos individuais (no Esxtop, os valores em % por núcleo estão disponíveis). Para cada núcleo, é possível consultar o Uso em MHz.
Como analisar? Às vezes, um aplicativo não está otimizado para a arquitetura multicloud: utiliza 100% apenas um núcleo, enquanto os outros permanecem ociosos. Por exemplo, com as configurações padrão, o backup do MS SQL é executado apenas em um núcleo. Como resultado, o backup é lento não por causa da baixa velocidade dos discos (que foi o que o usuário reclamou inicialmente), mas devido à incapacidade do processador. O problema foi resolvido alterando as configurações: o backup começou a ser executado em paralelo em vários arquivos (portanto, em vários processos).
Exemplo de carga desigual entre núcleos.
Também há situações (como mostrado no gráfico acima), onde os núcleos estão carregados de maneira desigual e alguns deles apresentam picos de 100%. Assim como ocorre ao carregar apenas um núcleo, o alerta de Uso de CPU não será acionado (ele é geral na VM), mas haverão problemas de desempenho.
O que fazer? Se o software na máquina virtual sobrecarrega os núcleos de maneira desigual (utiliza apenas um núcleo ou parte dos núcleos), não faz sentido aumentar sua quantidade. Nesse caso, é melhor mover a VM para um servidor com processadores mais potentes.
Você também pode tentar verificar as configurações de consumo de energia na BIOS do servidor. Muitos administradores ativam o modo Alto Desempenho na BIOS e, assim, desativam as tecnologias de economia de energia C-states e P-states. Nos processadores Intel modernos, é utilizada a tecnologia Turbo Boost, que aumenta a frequência de núcleos individuais do processador em detrimento de outros núcleos. Mas isso só funciona quando as tecnologias de economia de energia estão ativadas. Se as desativamos, o processador não consegue reduzir o consumo de energia dos núcleos que não estão carregados.
A VMware recomenda não desativar as tecnologias de economia de energia nos servidores, mas sim escolher modos que entreguem ao hipervisor o máximo de controle sobre o consumo de energia. Nesse caso, nas configurações de consumo de energia do hipervisor, deve-se escolher o modo Alto Desempenho.
Se em sua infraestrutura, VMs separadas (ou núcleos de VMs) exigem uma frequência de CPU aumentada, a configuração correta do consumo de energia pode melhorar significativamente seu desempenho.
CPU Ready (Prontidão)
Se o núcleo da VM (vCPU) estiver no estado Ready, ele não está realizando trabalho útil. Esse estado ocorre quando o hypervisor não encontra um núcleo físico livre ao qual pode atribuir o processo vCPU da máquina virtual.
Como analisar? Geralmente, se os núcleos da máquina virtual estiverem no estado Ready por mais de 10% do tempo, você notará problemas de desempenho. Em termos simples, mais de 10% do tempo a VM está aguardando a disponibilidade de recursos físicos.
No vCenter, é possível ver 2 contadores relacionados ao CPU Ready:
- Readiness,
- Ready.
Os valores de ambos os contadores podem ser vistos tanto para toda a VM quanto para núcleos individuais.
O Readiness mostra o valor imediatamente em porcentagens, mas apenas em tempo real (dados da última hora, intervalo de medição de 20 segundos). Esse contador é melhor utilizado apenas para identificar problemas "no calor do momento".
Os valores do contador Ready também podem ser vistos em uma perspectiva histórica. Isso é útil para estabelecer padrões e para uma análise mais profunda do problema. Por exemplo, se uma máquina virtual começa a ter problemas de desempenho em um determinado horário, é possível correlacionar os intervalos de aumento do valor do CPU Ready com a carga total no servidor onde a VM está operando, e tomar medidas para reduzir a carga (caso o DRS não tenha resolvido).
Diferente do Readiness, o Ready é mostrado não em porcentagens, mas em milissegundos. Este contador é do tipo Summation, ou seja, ele indica quanto tempo, durante o período de medição, o núcleo da VM ficou no estado Ready. Esse valor pode ser convertido em porcentagens por uma fórmula simples:
(valor de somação do CPU ready / (intervalo de atualização padrão do gráfico em segundos * 1000)) * 100 = CPU ready %
Por exemplo, para a VM no gráfico abaixo, o valor máximo de Ready para toda a máquina virtual será o seguinte:
Ao calcular o valor de Ready em porcentagens, é importante prestar atenção a dois pontos:
- O valor de Ready para toda a VM é a soma do Ready nos núcleos.
- O intervalo de medição. Para Real-time, é de 20 segundos, enquanto, por exemplo, nos gráficos diários, é de 300 segundos.
Durante uma solução de problemas ativa, é fácil ignorar esses pontos simples e desperdiçar tempo valioso resolvendo problemas inexistentes.
Vamos calcular o Ready com base nos dados do gráfico abaixo. (324474/(20*1000))*100 = 1622% para toda a VM. Se olharmos por núcleos, a situação já não é tão assustadora: 1622/64 = 25% por núcleo. Neste caso, descobrir o engano é bastante simples: o valor de Ready é irrealista. Mas se estamos falando de 10–20% para toda a VM com vários núcleos, então o valor por núcleo pode estar dentro da norma.
O que fazer? Um alto valor de Ready indica que o servidor carece de recursos de CPU para o funcionamento adequado das máquinas virtuais. Nessa situação, a única solução é reduzir a super-alocação de CPU (vCPU:pCPU). É evidente que isso pode ser conseguido diminuindo os parâmetros das VMs existentes ou migrando parte das VMs para outros servidores.
Co-stop
Como analisar? Esse contador também é do tipo Summation e é traduzido em porcentagens de forma semelhante ao Ready:
(valor de soma da CPU co-stop / (intervalo de atualização padrão do gráfico em segundos * 1000)) * 100 = % de co-stop da CPU
Aqui também é importante prestar atenção ao número de núcleos na VM e ao intervalo de medição.
No estado co-stop, o núcleo não está realizando trabalho útil. Com a escolha correta do tamanho da VM e uma carga normal no servidor, o contador de co-stop deve estar próximo de zero.
Neste caso, a carga está claramente anormal :)
O que fazer? Se várias VMs com muitos núcleos estiverem em um único hipervisor e houver super-alocação de CPU, o contador de co-stop pode aumentar, levando a problemas de desempenho para essas VMs.
O co-stop também aumentará se threads em um único núcleo físico do servidor com hyper-threading estiverem sendo usadas para núcleos ativos de uma VM. Essa situação pode ocorrer, por exemplo, se a VM tiver mais núcleos do que existem fisicamente no servidor onde está sendo executada, ou se a configuração "preferHT" estiver ativada para a VM. Sobre essa configuração, você pode ler .
Para evitar problemas de desempenho na VM devido a um alto co-stop, escolha o tamanho da VM de acordo com as recomendações do fabricante do software que está sendo executado nessa VM e com as capacidades do servidor físico onde a VM opera.
Não adicione núcleos em excesso, isso pode causar problemas de desempenho não apenas na própria VM, mas também nas suas vizinhas no servidor.
Outras métricas úteis de CPU
Run – quanto tempo (ms) durante o período de medição a vCPU esteve no estado RUN, ou seja, realizando trabalho útil.
Idle – quanto tempo (ms) o vCPU esteve em estado de inatividade durante o período de medição. Altos valores de inatividade não são um problema, simplesmente significam que o vCPU não tinha "o que fazer".
Aguardar – quanto tempo (ms) o vCPU esteve em estado de espera durante o período de medição. Como este contador inclui o IDLE, altos valores de espera também não indicam necessariamente um problema. No entanto, se o IDLE for baixo enquanto a espera for alta, significa que a VM estava aguardando a conclusão de operações de entrada/saída, o que pode indicar problemas de desempenho do disco rígido ou de dispositivos virtuais na VM.
Limite máximo – quanto tempo (ms) o vCPU esteve em estado de pronto devido a um limite de recursos estabelecido. Se o desempenho estiver inexplicavelmente baixo, é útil verificar o valor deste contador e o limite de CPU nas configurações da VM. A VM pode realmente ter limites que você desconhece. Isso acontece, por exemplo, quando a VM foi clonada a partir de um modelo onde havia um limite de CPU configurado.
Espera por Swap – quanto tempo o vCPU aguardou operações com o Swap do VMkernel durante o período de medição. Se os valores deste contador forem superiores a zero, a VM certamente está enfrentando problemas de desempenho. Vamos falar mais sobre SWAP no artigo sobre os contadores de memória.
ESXTOP
Se os contadores de desempenho no vCenter são bons para análise de dados históricos, uma análise rápida do problema é melhor realizada no ESXTOP. Aqui, todos os valores são apresentados de forma acessível (não há necessidade de tradução), e o período mínimo de medição é de 2 segundos.
A tela do ESXTOP para CPU é chamada pela tecla "c" e se parece com isto:
Para facilitar, você pode deixar apenas os processos das máquinas virtuais pressionando Shift-V.
Para visualizar métricas de núcleos individuais da VM, pressione "e" e insira o GID da VM de interesse (30919 na captura de tela abaixo):
Vou passar rapidamente pelas colunas apresentadas por padrão. Colunas adicionais podem ser adicionadas pressionando "f".
NWLD (Número de Mundos) – número de processos no grupo. Para expandir o grupo e ver as métricas para cada processo (por exemplo, para cada núcleo em uma VM multi-core), pressione “e”. Se houver mais de um processo no grupo, os valores das métricas do grupo são iguais à soma das métricas de cada processo individual.
%USED – quanto ciclos de CPU o servidor utiliza o processo ou grupo de processos.
%RUN – quanto tempo, durante o período de medição, o processo esteve no estado RUN, ou seja, realizando trabalho útil. Difere de %USED por não considerar hyper-threading, escalonamento de frequência e o tempo gasto em tarefas do sistema (%SYS).
%SYS – tempo gasto em tarefas do sistema, como processamento de interrupções, entrada/saída, funcionamento da rede, etc. O valor pode ser alto se a VM tiver muita entrada/saída.
%OVRLP – quanto tempo o núcleo físico, no qual o processo da VM está sendo executado, gastou em tarefas de outros processos.
Essas métricas estão relacionadas da seguinte forma:
%USED = %RUN + %SYS — %OVRLP.
Normalmente, a métrica %USED é mais informativa.
%WAIT – quanto tempo, durante o período de medição, o processo esteve no estado Wait. Inclui IDLE.
%IDLE – quanto tempo, durante o período de medição, o processo esteve no estado IDLE.
%SWPWT – quanto tempo, durante o período de medição, o vCPU esperou por uma operação com o VMkernel Swap.
%VMWAIT – quanto tempo, durante o período de medição, o vCPU esteve no estado de espera por um evento (normalmente entrada/saída). Não há um contador correspondente no vCenter. Valores altos indicam problemas de entrada/saída na VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Se a VM não utiliza o VMkernel Swap, ao analisar problemas de desempenho, é aconselhável observar o %VMWAIT, pois essa métrica não considera o tempo em que a VM não estava fazendo nada (%IDLE).
%RDY – quanto tempo, durante o período de medição, o processo esteve no estado Ready.
%CSTP – quanto tempo, durante o período de medição, o processo esteve no estado costop.
%MLMTD – quanto tempo, durante o período de medição, o vCPU esteve no estado Ready devido a um limite de recursos estabelecido.
%WAIT + %RDY + %CSTP + %RUN = 100% – o núcleo da VM está sempre em um desses quatro estados.
CPU no hipervisor
No vCenter, também existem contadores de desempenho de CPU para o hipervisor, mas eles não representam nada interessante – são apenas a soma dos contadores de todas as VMs no servidor.
É mais conveniente observar o estado da CPU no servidor na aba Resumo:
Para o servidor, assim como para a máquina virtual, existe um Alarm padrão:
Sob alta carga na CPU do servidor, as VMs que nele operam começam a ter problemas de desempenho.
No ESXTOP, os dados de carga da CPU do servidor são apresentados na parte superior da tela. Além da carga padrão da CPU, que é pouco informativa para hipervisores, existem mais três métricas:
UTILIZAÇÃO DO CORE(%) – carga do núcleo do servidor físico. Este contador mostra quanto tempo, durante o período de medição, o núcleo esteve executando trabalho.
UTILIZAÇÃO DO PCPU(%) – se o hyper-threading estiver ativado, cada núcleo físico terá dois threads (PCPU). Esta métrica mostra quanto tempo cada thread esteve executando trabalho.
PCPU UTILIZADO(%) – o mesmo que PCPU UTIL(%), mas considera o frequency scaling (ou seja, a redução da frequência do núcleo para economia de energia, ou o aumento da frequência do núcleo através da tecnologia Turbo Boost) e o hyper-threading.
PCPU_USED% = PCPU_UTIL% * frequência efetiva do núcleo / frequência nominal do núcleo.
Nesta captura de tela, para alguns núcleos, devido ao trabalho do Turbo Boost, o valor USED é superior a 100%, já que a frequência do núcleo está acima da nominal.
Algumas palavras sobre como o hyper-threading é considerado. Se os processos são executados 100% do tempo em ambos os threads do núcleo físico do servidor, e o núcleo opera na frequência nominal, então:
- A UTILIZAÇÃO DO CORE para o núcleo será de 100%,
- A UTILIZAÇÃO DO PCPU para ambos os threads será de 100%,
- O PCPU UTILIZADO para ambos os threads será de 50%.
Se ambos os threads não estiverem ativos 100% do tempo durante o período de medição, então, nos períodos em que os threads trabalharam paralelamente, o PCPU UTILIZADO para os núcleos é dividido por dois.
No ESXTOP também há uma tela com os parâmetros de consumo de energia da CPU do servidor. Aqui é possível verificar se o servidor está utilizando tecnologias de economia de energia: C-states e P-states. É acionado pela tecla 'p':
Problemas padrão de desempenho da CPU
Por fim, vou passar por causas típicas de problemas de desempenho da CPU da VM e dar dicas breves para resolvê-los:
Falta de frequência do núcleo. Se não houver como mover a VM para núcleos mais potentes, experimente mudar as configurações de energia para que o Turbo Boost funcione de forma mais eficaz.
Dimensionamento incorreto da VM (muitos/poucos núcleos). Se houver poucos núcleos, a carga da CPU da VM será alta. Se houver muitos, você terá um co-stop alto.
Grande sobrecarga de CPU no servidor. Se a VM tiver um valor alto de Ready, reduza a sobrecarga de CPU.
Topologia NUMA incorreta em grandes VMs. A topologia NUMA que a VM (vNUMA) vê deve corresponder à topologia NUMA do servidor (pNUMA). Sobre o diagnóstico e possíveis soluções para esse problema, escrito, por exemplo, no livro . Se você não quiser se aprofundar e não tiver restrições de licença para o SO instalado na VM, faça várias soquetes virtuais na VM com um núcleo cada. Você não vai perder muito 🙂
É isso sobre CPU por enquanto. Faça suas perguntas. Na próxima parte, irei falar sobre memória RAM.
Links Úteis
Fonte: habr.com
