Neste artigo, vamos falar sobre contadores de desempenho da memória RAM no vSphere.
Parece que a memória é mais clara do que o processador: se houver problemas de desempenho na VM, é difícil não notar. Mas, se eles aparecerem, é muito mais complicado resolvê-los. Vamos falar sobre tudo isso.
Um pouco de teoria
A memória RAM das máquinas virtuais vem da memória do servidor em que as VMs estão rodando. Isso é bastante óbvio :). Se a memória RAM do servidor não for suficiente para todos os que desejam, o ESXi começa a aplicar técnicas de otimização do consumo de memória (memory reclamation techniques). Caso contrário, os sistemas operacionais das VMs falhariam com erros de acesso à RAM.
Quais técnicas o ESXi aplica depende da carga da memória:
Estado da memória
Limite
Ações
Alto
400% do minFree
Após atingir o limite superior, as grandes páginas de memória são divididas em pequenas (TPS opera no modo padrão).
Limpar
100% do minFree
Grandes páginas de memória são divididas em pequenas, o TPS opera forçadamente.
Soft
64% do minFree
TPS + Balloon
Difícil
32% do minFree
TPS + Compress + Swap
Baixo
16% do minFree
Compress + Swap + Block
minFree é a memória RAM necessária para o funcionamento do hipervisor.
Até o ESXi 4.1 incluído, o minFree era fixo por padrão — 6% do volume de RAM do servidor (a porcentagem podia ser alterada pela opção Mem.MinFreePct no ESXi). Nas versões posteriores, devido ao aumento dos volumes de memória nos servidores, o minFree passou a ser calculado com base no volume de memória do host, e não como um valor percentual fixo.
O valor do minFree (por padrão) é calculado da seguinte forma:
Porcentagem de memória reservada para minFree
Faixa de memória
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Memória restante
Por exemplo, para um servidor com 128 GB de RAM, o valor de MinFree seria:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
O valor real pode diferir por algumas centenas de MB, dependendo do servidor e da memória RAM.
Porcentagem de memória reservada para minFree
Faixa de memória
Valor para 128 GB
6%
0-4 GB
245,76 MB
4%
4-12 GB
327,68 MB
2%
12-28 GB
327,68 MB
1%
Memória restante (100 GB)
1024 MB
Normalmente, para ambientes produtivos, apenas o estado High pode ser considerado adequado. Para ambientes de teste e desenvolvimento, os estados Clear/Soft podem ser aceitáveis. Se a memória RAM no host estiver abaixo de 64% MinFree, as VMs que operam nele certamente apresentarão problemas de desempenho.
Em cada estado, são aplicadas técnicas específicas de recuperação de memória, começando pelo TPS, que praticamente não afeta o desempenho das VMs, até o Swapping. Vou explicar mais sobre isso.
Transparent Page Sharing (TPS). TPS é, grosso modo, a deduplicação de páginas de memória RAM de máquinas virtuais no servidor.
O ESXi procura páginas de memória RAM iguais entre as máquinas virtuais, calculando e comparando os hashes das páginas, e remove as duplicatas, substituindo-as por referências à mesma página na memória física do servidor. Como resultado, o consumo de memória física é reduzido e é possível obter um certo overcommitment de memória praticamente sem perda de desempenho.
Este mecanismo funciona apenas para páginas de memória de 4 KB (small pages). O hipervisor sequer tenta deduplicar páginas de 2 MB (large pages): a probabilidade de encontrar páginas idênticas desse tamanho não é grande.
Por padrão, o ESXi aloca memória para large pages. A fragmentação de large pages em small pages começa ao atingir o limiar do estado High e ocorre forçadamente quando o estado Clear é alcançado (veja a tabela de estados do hipervisor).
Se você deseja que o TPS comece a funcionar sem esperar que a memória RAM do host fique cheia, nas Opções Avançadas do ESXi é necessário definir o valor “Mem.AllocGuestLargePage” como 0 (por padrão 1). Assim, a alocação de large pages para máquinas virtuais será desativada.
Desde dezembro de 2014, em todas as versões do ESXi, o TPS entre VMs está desativado por padrão, pois foi descoberta uma vulnerabilidade que teoricamente permite acessar a memória RAM de outra VM a partir de uma. Mais detalhes aqui. Não encontrei informação sobre a implementação prática da exploração da vulnerabilidade TPS.
A política de TPS é controlada através da opção avançada “Mem.ShareForceSalting” no ESXi:
0 — Inter-VM TPS. O TPS funciona para páginas de diferentes VMs;
1 – TPS para VMs com o mesmo valor de “sched.mem.pshare.salt” no VMX;
2 (por padrão) – Intra-VM TPS. O TPS funciona para páginas dentro da VM.
Definitivamente faz sentido desativar páginas grandes e ativar o Inter-VM TPS em ambientes de teste. Isso também pode ser utilizado em ambientes com um grande número de VMs idênticas. Por exemplo, em ambientes com VDI, a economia de memória física pode alcançar dezenas de porcento.
Memory Ballooning. O Ballooning não é mais uma técnica tão inofensiva e transparente para o sistema operacional da VM como o TPS. Mas, se aplicado corretamente, é possível viver e até trabalhar com o Ballooning.
Junto com o VMware Tools, é instalado na VM um driver especial chamado Balloon Driver (vmmemctl). Quando o hipervisor começa a ficar sem memória física e entra no estado Soft, o ESXi solicita à VM que devolva a memória RAM não utilizada através deste Balloon Driver. O driver, por sua vez, atua no nível do sistema operacional e solicita memória livre a ele. O hipervisor vê quais páginas de memória física foram ocupadas pelo Balloon Driver, retira a memória da máquina virtual e a devolve ao host. Não há problemas no funcionamento do SO, já que no nível do SO a memória está ocupada pelo Balloon Driver. Por padrão, o Balloon Driver pode retirar até 65% da memória da VM.
Se o VMware Tools não estiver instalado na VM ou se o Ballooning estiver desativado (não recomendo, mas existe :), o hipervisor imediatamente recorre a técnicas mais rígidas de recuperação de memória. Conclusão: certifique-se de que o VMware Tools esteja instalado na VM.
O funcionamento do Balloon Driver pode ser verificado a partir do SO através do VMware Tools..
Memory Compression. Esta técnica é aplicada quando o ESXi chega ao estado Hard. Como o próprio nome sugere, o ESXi tenta comprimir as páginas de 4 Kbytes de memória RAM para 2 Kbytes e, assim, liberar um pouco de espaço na memória física do servidor. Essa técnica aumenta significativamente o tempo de acesso ao conteúdo das páginas de memória da VM, uma vez que a página precisa ser descomprimida previamente. Às vezes, nem todas as páginas conseguem ser comprimidas, e o próprio processo leva um certo tempo. Portanto, essa técnica na prática não é muito eficaz.
Memory Swapping. Após uma breve fase de Memory Compression, o ESXi praticamente inevitavelmente (se as VMs não migraram para outros hosts ou não foram desligadas) passa para o Swapping. E se a memória restante for muito baixa (estado Low), o hipervisor também para de alocar páginas de memória para as VMs, o que pode causar problemas nos sistemas operacionais convidados das VMs.
É assim que funciona o Swapping. Ao ligar a máquina virtual, é criado um arquivo com a extensão .vswp. O tamanho desse arquivo é igual à memória RAM não reservada da MV: é a diferença entre a memória configurada e a memória reservada. Durante o funcionamento do Swapping, o ESXi descarrega as páginas de memória da máquina virtual para esse arquivo e começa a trabalhar com ele em vez da memória física do servidor. Claro, essa memória “operacional” é significativamente mais lenta do que a verdadeira, mesmo que o .vswp esteja em um armazenamento rápido.
Ao contrário do Ballooning, onde páginas não utilizadas são retiradas da MV, no Swapping, páginas que estão ativamente em uso pelo sistema operacional ou aplicações dentro da MV podem ser transferidas para o disco. Como resultado, o desempenho da MV cai drasticamente, podendo até travar. A MV formalmente continua funcionando e pelo menos pode ser desligada corretamente a partir do sistema operacional. Se você tiver paciência 😉
Se a MV foi para o Swap — isso é uma situação anômala, que deve ser evitada sempre que possível.
Principais contadores de desempenho da memória da máquina virtual
Agora chegamos ao principal. Para monitorar o estado da memória na MV, existem os seguintes contadores:
Active — mostra o volume de memória operacional (KB) ao qual a MV teve acesso no período anterior de medição.
Usage — o mesmo que Active, mas em porcentagem da memória operacional configurada da MV. É calculado pela seguinte fórmula: active ÷ tamanho da memória configurada da máquina virtual.
Um alto Usage e Active, respectivamente, nem sempre são indicadores de problemas de desempenho da MV. Se a MV utiliza agressivamente a memória (pelo menos, está acessando-a), isso não significa que está sem memória. É mais um motivo para verificar o que está acontecendo no sistema operacional.
Há um Alarme padrão por Uso de Memória para a MV:
Compartilhado — volume de memória operacional da MV, desduplicada com TPS (dentro da MV ou entre MVs).
Concedido — volume de memória física do host (KB) que foi alocada para a MV. Inclui o compartilhado.
Consumido (Concedido — Compartilhado) — volume de memória física (KB) que a MV consome do host. Não inclui o compartilhado.
Se parte da memória da MV for alocada não da memória física do host, mas de um arquivo de swap ou a memória for retirada da MV através do Balloon Driver, esse volume não é contabilizado em Concedido e Consumido.
Valores altos de Granted e Consumed são completamente normais. O sistema operacional gradualmente retira memória do hypervisor e não a devolve. Com o tempo, para uma VM que está em operação ativa, os valores desses contadores se aproximam da quantidade de memória configurada e permanecem lá.
Zero — a quantidade de memória RAM da VM (Kbytes) que contém zeros. Essa memória é considerada livre pelo hypervisor e pode ser alocada para outras máquinas virtuais. Após a guest OS escrever algo na memória zerada, ela passa para Consumed e não retorna mais.
Reserved Overhead — a quantidade de memória RAM da VM (Kbytes) reservada pelo hypervisor para o funcionamento da VM. É um pequeno volume, mas deve estar disponível no host; caso contrário, a VM não iniciará.
Balloon — a quantidade de memória RAM (Kbytes) retirada da VM através do Balloon Driver.
Compressed — a quantidade de memória RAM (Kbytes) que foi comprimida.
Swapped — a quantidade de memória RAM (Kbytes) que, por falta de memória física no servidor, foi movida para o disco.
Balloon e outros contadores de técnicas de recuperação de memória são iguais a zero.
Assim é como aparece o gráfico com os contadores de uma VM funcionando normalmente com 150 GB de RAM.
No gráfico abaixo, a VM apresenta problemas claros. Abaixo do gráfico, pode-se ver que todas as técnicas de gerenciamento de memória foram aplicadas a esta VM. O Balloon para esta VM é consideravelmente maior do que o Consumed. Na verdade, a VM está mais morta do que viva.
ESXTOP
Assim como com a CPU, se queremos avaliar rapidamente a situação no host e sua dinâmica em intervalos de até 2 segundos, é bom usar o ESXTOP.
A tela do ESXTOP para Memória é chamada com a tecla 'm' e aparece da seguinte forma (campos B, D, H, J, K, L, O foram selecionados):
Os parâmetros interessantes para nós serão os seguintes:
Mem overcommit avg — valor médio de sobrecompromisso de memória no host por 1, 5 e 15 minutos. Se for maior que zero, é um motivo para verificar o que está acontecendo, mas nem sempre indica a presença de problemas.
Na linha PMEM/MB e VMKMEM/MB — informações sobre a memória física do servidor e a memória disponível para o VMkernel. Aqui, podemos ver o valor de minfree (em MB), o estado da memória do host (neste caso, alto).
Na linha NUMA/MB pode-se ver a distribuição da memória RAM pelos nós NUMA (sockets). Neste exemplo, a distribuição é desigual, o que, em princípio, não é muito bom.
A seguir, estão as estatísticas gerais do servidor sobre técnicas de recuperação de memória:
PSHARE/MB — são estatísticas TPS;
SWAP/MB — estatísticas de uso de Swap;
ZIP/MB — estatísticas de compressão de páginas de memória;
MEMCTL/MB — estatísticas de utilização do Balloon Driver.
Para máquinas virtuais individuais, podemos nos interessar pelas seguintes informações. Os nomes das VMs foram ocultados para não confundir o público:). Se a métrica ESXTOP for semelhante ao contador no vSphere, trago o contador correspondente.
MEMSZ — volume de memória configurado na VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.
GRANT — Granted em MB.
TCHD — Active em MB.
MCTL? — se o Balloon Driver está instalado na VM.
MCTLSZ — Balloon em MB.
MCTLGT — volume de memória RAM (MB) que o ESXi deseja retirar da VM através do Balloon Driver (Memctl Target).
MCTLMAX — volume máximo de memória RAM (MB) que o ESXi pode retirar da VM através do Balloon Driver.
SWCUR — volume atual de memória RAM (MB) alocado à VM a partir do arquivo Swap.
SWGT — volume de memória RAM (MB) que o ESXi deseja alocar à VM a partir do arquivo Swap (Swap Target).
Através do ESXTOP, também é possível ver informações mais detalhadas sobre a topologia NUMA da VM. Para isso, é necessário selecionar os campos D,G:
NHN – Nós NUMA nos quais a VM está localizada. Aqui, podemos imediatamente notar VMs amplas que não cabem em um único nó NUMA.
NRMEM – quantos megabytes de memória a VM está retirando de um nó NUMA remoto.
NLMEM – quantos megabytes de memória a VM está retirando de um nó NUMA local.
N%L – porcentagem de memória da VM no nó NUMA local (se menos de 80% — podem surgir problemas de desempenho).
Memória no hipervisor
Se os contadores de CPU do hipervisor geralmente não são de interesse especial, a situação é oposta com a memória. Um alto uso de memória na VM nem sempre indica um problema de desempenho, mas um alto uso de memória no hipervisor definitivamente inicia as técnicas de gerenciamento de memória e causa problemas de desempenho na VM. Devemos monitorar os alarmes de uso de memória do host e evitar que a VM entre em Swap.
Unswap
Se a VM entrar em Swap, seu desempenho diminui significativamente. Os vestígios de Ballooning e compressão desaparecem rapidamente após a chegada de memória RAM livre no host, mas a máquina virtual não se apressa a voltar do Swap para a memória RAM do servidor.
Até a versão ESXi 6.0, a única maneira confiável e rápida de tirar uma VM do Swap era reiniciar (mais especificamente, desligar/ligar o contêiner). A partir do ESXi 6.0, surgiu um método que, embora não oficialmente reconhecido, é funcional e seguro para remover VMs do Swap. Em uma das conferências, conversei com um dos engenheiros da VMware que trabalha no CPU Scheduler. Ele confirmou que o método é totalmente funcional e seguro. Em nossa experiência, não tivemos problemas com isso.
Comandos para tirar VMs do Swap Duncan Epping. Não vou repetir a descrição detalhada, apenas vou dar um exemplo de uso. Como pode ser visto na captura de tela, algum tempo após a execução do comando fornecido, o Swap na VM desaparece.
Dicas para gerenciar a memória RAM no ESXi
Por fim, aqui estão algumas dicas que podem ajudá-lo a evitar problemas de desempenho em VMs causados pela memória RAM:
- Evite a superutilização de memória RAM em clusters produtivos. É recomendável sempre manter cerca de 20-30% de memória livre no cluster, para que o DRS (e o administrador) tenha espaço para manobras, e durante a migração as VMs não sejam enviadas ao Swap. Além disso, não se esqueça de deixar uma reserva para a tolerância a falhas. É desagradável quando, ao falhar um servidor e reiniciar VMs com HA, algumas máquinas ainda vão para o Swap.
- Em infraestruturas com alta consolidação, tente NÃO criar VMs com mais da metade da memória do host. Isso, novamente, ajudará o DRS a distribuir as máquinas virtuais pelos servidores do cluster sem problemas. Essa regra, é claro, não é universal :).
- Fique atento ao Alarme de Uso de Memória do Host.
- Não se esqueça de instalar o VMware Tools nas VMs e não desative o Ballooning.
- Considere ativar o Inter-VM TPS e desativar o Large Pages em ambientes com VDI e em ambientes de teste.
- Se a VM estiver enfrentando problemas de desempenho, verifique se ela não está usando memória de um nó NUMA remoto.
- Tire as VMs do Swap o mais rápido possível! Além disso, se a VM estiver no Swap, por motivos óbvios, o armazenamento será afetado.
Isso é tudo que tenho sobre memória RAM. Abaixo, artigos sobre o tema para aqueles que desejam se aprofundar nos detalhes. O próximo artigo será dedicado ao armazenamento.
Links Úteis
Fonte: habr.com
