Se você administra uma infraestrutura virtual baseada em VMware vSphere (ou qualquer outra pilha de tecnologia), provavelmente ouvirá reclamações dos usuários com frequência: “A máquina virtual está lenta!” Nesta série de artigos analisarei as métricas de desempenho e direi o que e por que isso desacelera e como garantir que não desacelere.
Considerarei os seguintes aspectos do desempenho da máquina virtual:
- CPU,
- RAM,
- DISCO,
- Rede.
Vou começar com a CPU.
Para analisar o desempenho precisaremos de:
- Contadores de desempenho do vCenter – contadores de desempenho, cujos gráficos podem ser visualizados por meio do vSphere Client. As informações sobre esses contadores estão disponíveis em qualquer versão do cliente (cliente “thick” em C#, cliente web em Flex e cliente web em HTML5). Nestes artigos usaremos capturas de tela do cliente C#, apenas porque ficam melhores em miniatura :)
- ESXTOP – um utilitário executado na linha de comando do ESXi. Com sua ajuda, você pode obter os valores dos contadores de desempenho em tempo real ou fazer upload desses valores de um determinado período em um arquivo .csv para análise posterior. A seguir, contarei mais sobre essa ferramenta e fornecerei vários links úteis para documentação e artigos sobre o assunto.
Um pouco de teoria
No ESXi, um processo separado – mundo na terminologia VMware – é responsável pela operação de cada vCPU (núcleo de máquina virtual). Existem também processos de serviço, mas do ponto de vista da análise do desempenho da VM eles são menos interessantes.
Um processo no ESXi pode estar em um dos quatro estados:
- Execute – o processo realiza algum trabalho útil.
- Espere – o processo não está realizando nenhum trabalho (ocioso) ou está aguardando entrada/saída.
- Custo – uma condição que ocorre em máquinas virtuais multi-core. Ocorre quando o agendador de CPU do hipervisor (ESXi CPU Scheduler) não consegue agendar a execução simultânea de todos os núcleos ativos da máquina virtual nos núcleos do servidor físico. No mundo físico, todos os núcleos do processador funcionam em paralelo, o sistema operacional convidado dentro da VM espera um comportamento semelhante, portanto, o hipervisor precisa desacelerar os núcleos da VM que têm a capacidade de terminar seu ciclo de clock mais rapidamente. Nas versões modernas do ESXi, o agendador da CPU usa um mecanismo chamado co-agendamento relaxado: o hipervisor considera a lacuna entre o núcleo da máquina virtual “mais rápido” e o “mais lento” (inclinação). Se a lacuna exceder um certo limite, o núcleo rápido entra no estado costop. Se os núcleos da VM passarem muito tempo nesse estado, isso poderá causar problemas de desempenho.
- Pronto – o processo entra neste estado quando o hipervisor não consegue alocar recursos para sua execução. Valores altos de prontidão podem causar problemas de desempenho da VM.
Contadores básicos de desempenho de CPU de máquina virtual
Utilização do CPU, %. Mostra a porcentagem de uso da CPU em um determinado período.
Como analisar? Se uma VM usa CPU consistentemente a 90% ou há picos de até 100%, então temos problemas. Os problemas podem ser expressos não apenas na operação “lenta” da aplicação dentro da VM, mas também na inacessibilidade da VM pela rede. Se o sistema de monitoramento mostrar que a VM cai periodicamente, preste atenção aos picos no gráfico de uso da CPU.
Existe um alarme padrão que mostra a carga da CPU da máquina virtual:
O que fazer? Se o uso da CPU de uma VM está constantemente aumentando, você pode pensar em aumentar o número de vCPUs (infelizmente, isso nem sempre ajuda) ou mover a VM para um servidor com processadores mais potentes.
Uso da CPU em MHz
Nos gráficos do vCenter Usage em% você pode ver apenas para toda a máquina virtual; não há gráficos para núcleos individuais (no Esxtop existem valores% para núcleos). Para cada núcleo você pode ver o uso em MHz.
Como analisar? Acontece que uma aplicação não está otimizada para uma arquitetura multi-core: ela utiliza apenas um núcleo 100%, e os demais ficam ociosos sem carga. Por exemplo, com configurações de backup padrão, o MS SQL inicia o processo em apenas um núcleo. Como resultado, o backup fica lento não por causa da lentidão dos discos (foi disso que o usuário reclamou inicialmente), mas porque o processador não consegue lidar com isso. O problema foi resolvido alterando os parâmetros: o backup passou a rodar paralelamente em vários arquivos (respectivamente, em vários processos).
Um exemplo de carga desigual nos núcleos.
Também existe uma situação (como no gráfico acima) em que os núcleos são carregados de forma desigual e alguns deles apresentam picos de 100%. Assim como acontece com o carregamento de apenas um núcleo, o alarme de uso da CPU não funcionará (é para toda a VM), mas haverá problemas de desempenho.
O que fazer? Se o software em uma máquina virtual carrega os núcleos de forma desigual (usa apenas um núcleo ou parte dos núcleos), não faz sentido aumentar seu número. 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 no BIOS do servidor. Muitos administradores ativam o modo de alto desempenho no BIOS e, assim, desativam as tecnologias de economia de energia dos estados C e P. Os processadores Intel modernos usam a tecnologia Turbo Boost, que aumenta a frequência de núcleos de processador individuais em detrimento de outros núcleos. Mas só funciona quando as tecnologias de poupança de energia estão ligadas. Se os desabilitarmos, o processador não poderá reduzir o consumo de energia dos núcleos que não estão carregados.
A VMware recomenda não desabilitar as tecnologias de economia de energia nos servidores, mas escolher modos que deixem o gerenciamento de energia para o hipervisor, tanto quanto possível. Neste caso, nas configurações de consumo de energia do hipervisor, você precisa selecionar Alto Desempenho.
Se você tiver VMs individuais (ou núcleos de VM) em sua infraestrutura que exigem maior frequência de CPU, o ajuste correto do consumo de energia pode melhorar significativamente seu desempenho.
CPU pronta
Se o núcleo da VM (vCPU) estiver no estado Pronto, ele não realizará trabalho útil. Essa condição ocorre quando o hipervisor não encontra um núcleo físico livre ao qual o processo vCPU da máquina virtual possa ser atribuído.
Como analisar? Normalmente, se os núcleos de uma máquina virtual estiverem no estado Pronto por mais de 10% do tempo, você notará problemas de desempenho. Simplificando, mais de 10% do tempo a VM espera que os recursos físicos fiquem disponíveis.
No vCenter você pode visualizar 2 contadores relacionados ao CPU Ready:
- prontidão,
- Pronto.
Os valores de ambos os contadores podem ser visualizados para toda a VM e para núcleos individuais.
A prontidão mostra o valor imediatamente como uma porcentagem, mas apenas em tempo real (dados da última hora, intervalo de medição de 20 segundos). É melhor usar este contador apenas para procurar problemas “quentemente logo”.
Os valores dos contadores prontos também podem ser visualizados de uma perspectiva histórica. Isto é útil para estabelecer padrões e para uma análise mais profunda do problema. Por exemplo, se uma máquina virtual começar a apresentar problemas de desempenho em um determinado momento, você poderá comparar os intervalos do valor CPU Ready com a carga total no servidor onde esta VM está sendo executada e tomar medidas para reduzir a carga (se o DRS falhar).
Ready, ao contrário de Readiness, não é mostrado em porcentagens, mas em milissegundos. Este é um contador do tipo Somatório, ou seja, mostra quanto tempo durante o período de medição o núcleo da VM ficou no estado Pronto. Você pode converter esse valor em porcentagem usando uma fórmula simples:
(Valor da soma da CPU pronta / (intervalo de atualização padrão do gráfico em segundos * 1000)) * 100 = % de CPU pronta
Por exemplo, para a VM no gráfico abaixo, o valor de pico Pronto para toda a máquina virtual será o seguinte:
Ao calcular a porcentagem de Pronto, você deve prestar atenção a dois pontos:
- O valor Ready para toda a VM é a soma de Ready entre núcleos.
- Intervalo de medição. Para tempo real são 20 segundos e, por exemplo, em gráficos diários são 300 segundos.
Com a solução de problemas ativa, esses pontos simples podem ser facilmente perdidos e um tempo valioso pode ser desperdiçado na solução de problemas inexistentes.
Vamos calcular o Ready com base nos dados do gráfico abaixo. (324474/(20*1000))*100 = 1622% para toda a VM. Se você olhar para os núcleos, não é tão assustador: 1622/64 = 25% por núcleo. Nesse caso, o problema é bastante fácil de detectar: o valor Pronto não é realista. Mas se estamos falando de 10 a 20% para toda a VM com vários núcleos, então para cada núcleo o valor pode estar dentro da faixa normal.
O que fazer? Um valor Pronto alto indica que o servidor não possui recursos de processador suficientes para a operação normal das máquinas virtuais. Em tal situação, tudo o que resta é reduzir o excesso de assinaturas por processador (vCPU:pCPU). Obviamente, isso pode ser conseguido reduzindo os parâmetros das VMs existentes ou migrando parte das VMs para outros servidores.
Co-parada
Como analisar? Este contador também é do tipo Somatório e é convertido em porcentagens da mesma forma que Pronto:
(Valor da soma da parada conjunta da CPU / (intervalo de atualização padrão do gráfico em segundos * 1000)) * 100 = % de parada conjunta da CPU
Aqui você também precisa prestar atenção ao número de núcleos na VM e ao intervalo de medição.
No estado costop, o kernel não realiza trabalho útil. Com a seleção correta do tamanho da VM e carga normal no servidor, o contador de co-stop deve estar próximo de zero.
Neste caso, a carga é claramente anormal :)
O que fazer? Se várias VMs com um grande número de núcleos estiverem em execução em um hipervisor e houver excesso de assinaturas na CPU, o contador de co-stop poderá aumentar, o que levará a problemas de desempenho dessas VMs.
Além disso, o co-stop aumentará se os núcleos ativos de uma VM usarem threads em um núcleo de servidor físico com hipertreading habilitado. Esta situação pode surgir, por exemplo, se a VM tiver mais núcleos do que os disponíveis fisicamente no servidor onde está sendo executada, ou se a configuração “preferHT” estiver habilitada para a VM. Você pode ler sobre esta configuração .
Para evitar problemas com o desempenho da VM devido ao alto co-stop, selecione o tamanho da VM de acordo com as recomendações do fabricante do software executado nesta VM e com os recursos do servidor físico onde a VM é executada.
Não adicione núcleos na reserva; isso pode causar problemas de desempenho não apenas para a própria VM, mas também para seus vizinhos no servidor.
Outras métricas úteis de CPU
Execute – quanto tempo (ms) durante o período de medição a vCPU ficou no estado RUN, ou seja, estava realmente realizando um trabalho útil.
inativo – quanto tempo (ms) durante o período de medição a vCPU ficou em estado de inatividade. Valores altos de inatividade não são um problema, a vCPU simplesmente não tinha “nada para fazer”.
Espere – quanto tempo (ms) durante o período de medição a vCPU permaneceu no estado de espera. Como o IDLE está incluído neste contador, valores altos de Wait também não indicam problema. Mas se Wait IDLE estiver baixo quando Wait estiver alto, significa que a VM estava aguardando a conclusão das operações de E/S e isso, por sua vez, pode indicar um problema com o desempenho do disco rígido ou de qualquer dispositivo virtual da VM.
Máximo limitado – quanto tempo (ms) durante o período de medição a vCPU permaneceu no estado Pronto devido ao limite de recursos definido. Se o desempenho estiver inexplicavelmente baixo, é útil verificar o valor deste contador e o limite da CPU nas configurações da VM. Na verdade, as VMs podem ter limites dos quais você não tem conhecimento. Por exemplo, isso acontece quando uma VM foi clonada a partir de um modelo no qual o limite de CPU foi definido.
Trocar espera – quanto tempo durante o período de medição a vCPU esperou por uma operação com VMkernel Swap. Se os valores deste contador estiverem acima de zero, a VM definitivamente terá problemas de desempenho. Falaremos mais sobre SWAP no artigo sobre contadores de RAM.
ESXTOP
Se os contadores de desempenho no vCenter forem bons para analisar dados históricos, então a análise operacional do problema será melhor realizada no ESXTOP. Aqui todos os valores são apresentados já prontos (não há necessidade de traduzir nada), e o período mínimo de medição é de 2 segundos.
A tela ESXTOP da CPU é acessada com a tecla "c" e tem a seguinte aparência:
Por conveniência, você pode sair apenas dos processos da máquina virtual pressionando Shift-V.
Para visualizar métricas para núcleos de VM individuais, pressione “e” e insira o GID da VM de interesse (30919 na captura de tela abaixo):
Deixe-me examinar brevemente as 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 de cada processo (por exemplo, para cada núcleo em uma VM multi-core), pressione “e”. Se houver mais de um processo em um grupo, os valores das métricas do grupo serão iguais à soma das métricas dos processos individuais.
%USADO – quantos ciclos de CPU do servidor são usados por um processo ou grupo de processos.
%CORRER – quanto tempo durante o período de medição o processo esteve no estado RUN, ou seja, fez um trabalho útil. Difere de %USED porque não leva em consideração hyper-threading, escala de frequência e tempo gasto em tarefas do sistema (%SYS).
%SYS – tempo gasto em tarefas do sistema, por exemplo: processamento de interrupções, I/O, operação da rede, etc. O valor pode ser alto se a VM tiver uma grande I/O.
%OVRLP – quanto tempo o núcleo físico no qual o processo VM está sendo executado gastou em tarefas de outros processos.
Essas métricas se relacionam entre si da seguinte forma:
% USADO = % EXECUTAR + % SYS - % OVRLP.
Normalmente, a métrica% USADO é mais informativa.
%ESPERE – por quanto tempo durante o período de medição o processo ficou no estado Espera. Ativa o IDLE.
%PARADO – quanto tempo durante o período de medição o processo permaneceu no estado IDLE.
% SWPWT – quanto tempo durante o período de medição a vCPU esperou por uma operação com VMkernel Swap.
%VMWAIT – quanto tempo durante o período de medição a vCPU ficou no estado de espera por um evento (geralmente E/S). Não há contador semelhante no vCenter. Valores altos indicam problemas de E/S na VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Caso a VM não utilize VMkernel Swap, então ao analisar problemas de performance é aconselhável olhar para %VMWAIT, pois esta métrica não leva em consideração o tempo em que a VM não estava fazendo nada (%IDLE).
%RDY – por quanto tempo durante o período de medição o processo ficou no estado Pronto.
%CSTP – quanto tempo durante o período de medição o processo esteve no estado costop.
%MLMTD – por quanto tempo durante o período de medição a vCPU permaneceu no estado Pronto devido ao limite de recursos definido.
%WAIT + %RDY + %CSTP + %RUN = 100% – o núcleo da VM está sempre em um desses quatro estados.
CPU no hipervisor
O vCenter também possui contadores de desempenho de CPU para o hipervisor, mas eles não são nada interessantes - são simplesmente a soma dos contadores de todas as VMs no servidor.
A maneira mais conveniente de visualizar o status da CPU no servidor é na guia Resumo:
Para o servidor, assim como para a máquina virtual, existe um Alarme padrão:
Quando a carga da CPU do servidor é alta, as VMs em execução nele começam a apresentar 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 não é muito informativa para hipervisores, existem mais três métricas:
UTIL PRINCIPAL (%) – carregando o núcleo do servidor físico. Este contador mostra quanto tempo o núcleo executou trabalho durante o período de medição.
UTIL PCPU(%) – se o hyper-threading estiver habilitado, haverá dois threads (PCPU) por núcleo físico. Esta métrica mostra quanto tempo cada thread levou para concluir o trabalho.
PCPU USADO (%) – o mesmo que PCPU UTIL(%), mas leva em consideração a escala de frequência (seja reduzindo a frequência do núcleo para fins de economia de energia ou aumentando a frequência do núcleo devido à tecnologia Turbo Boost) e hyper-threading.
PCPU_USED% = PCPU_UTIL% * frequência de núcleo efetiva / frequência de núcleo nominal.
Nesta captura de tela, para alguns núcleos, devido ao Turbo Boost, o valor USADO é superior a 100%, pois a frequência do núcleo é superior à nominal.
Algumas palavras sobre como o hyper-threading é levado em consideração. Se os processos forem executados 100% do tempo em ambos os threads do núcleo físico do servidor, enquanto o núcleo opera na frequência nominal, então:
- CORE UTIL para o núcleo será 100%,
- PCPU UTIL para ambos os threads será 100%,
- PCPU USADO para ambos os threads será de 50%.
Se ambos os threads não funcionaram 100% do tempo durante o período de medição, então durante os períodos em que os threads funcionaram em paralelo, o PCPU USADO para os núcleos será dividido pela metade.
ESXTOP também possui uma tela com parâmetros de consumo de energia da CPU do servidor. Aqui você pode ver se o servidor usa tecnologias de economia de energia: estados C e estados P. Chamado com a tecla "p":
Problemas comuns de desempenho da CPU
Por fim, examinarei as causas típicas de problemas com o desempenho da CPU da VM e darei algumas dicas para resolvê-los:
A velocidade do clock principal não é suficiente. Se não for possível atualizar sua VM para núcleos mais potentes, você pode tentar alterar as configurações de energia para fazer o Turbo Boost funcionar com mais eficiência.
Dimensionamento incorreto da VM (muitos/poucos núcleos). Se você instalar poucos núcleos, haverá uma alta carga de CPU na VM. Se houver muito, pegue um co-stop alto.
Grande excesso de utilização de CPU no servidor. Se a VM tiver um nível de prontidão alto, reduza o excesso de assinaturas de CPU.
Topologia NUMA incorreta em VMs grandes. A topologia NUMA vista pela VM (vNUMA) deve corresponder à topologia NUMA do servidor (pNUMA). Diagnósticos e possíveis soluções para este problema estão escritos, por exemplo, no livro . Se você não quiser se aprofundar e não tiver restrições de licenciamento no sistema operacional instalado na VM, crie vários soquetes virtuais na VM, um núcleo por vez. Você não perderá muito :)
Isso é tudo para mim sobre a CPU. Pergunte. Na próxima parte falarei sobre RAM.
Links úteis
Fonte: habr.com