Neste artigo, falaremos sobre os contadores de desempenho da memória de acesso aleatório (RAM) no vSphere.
Parece que com a memória tudo fica mais claro do que com o processador: se uma VM tem problemas de performance, é difícil não perceber. Mas se eles aparecem, é muito mais difícil lidar com eles. Mas as primeiras coisas primeiro.
Um pouco de teoria
A RAM das máquinas virtuais é retirada da memória do servidor no qual as VMs estão sendo executadas. É bastante óbvio :). Se a RAM do servidor não for suficiente para todos, o ESXi começa a usar técnicas de recuperação de memória para otimizar o consumo de RAM. Caso contrário, os sistemas operacionais da VM travariam com erros de acesso à RAM.
Quais técnicas usar ESXi decide dependendo da carga de RAM:
Estado da memória
Fronteira
Atividade
Alta
400% do minGrátis
Depois de atingir o limite superior, as páginas de memória grandes são divididas em pequenas (o TPS funciona no modo padrão).
Limpar
100% do minGrátis
As páginas de memória grandes são divididas em pequenas, o TPS é forçado a funcionar.
Suave
64% do minGrátis
TPS + Balão
Queijos duros
32% do minGrátis
TPS + Comprimir + Trocar
Baixo
16% do minGrátis
Compactar + Trocar + Bloquear
minFree é a RAM necessária para o hipervisor funcionar.
Antes do ESXi 4.1 inclusive, o minFree era fixado por padrão - 6% da RAM do servidor (a porcentagem podia ser alterada por meio da opção Mem.MinFreePct no ESXi). Nas versões posteriores, devido ao aumento do tamanho da memória nos servidores, o minFree passou a ser calculado com base na quantidade de memória do host, e não em uma porcentagem fixa.
O valor minFree (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 MinFree seria:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
O valor real pode diferir em algumas centenas de MB, depende do servidor e da 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 povoamentos produtivos, apenas o estado Alto pode ser considerado normal. Para bancos de teste e desenvolvimento, os estados Clear/Soft podem ser aceitáveis. Se a RAM no host for inferior a 64% MinFree, as VMs em execução nele definitivamente terão problemas de desempenho.
Em cada estado, são aplicadas determinadas técnicas de recuperação de memória, começando com TPS, que praticamente não afeta o desempenho da VM, e terminando com Swapping. Eu vou te contar mais sobre eles.
Compartilhamento transparente de página (TPS). O TPS é, grosso modo, a desduplicação das páginas de memória da máquina virtual em um servidor.
O ESXi procura páginas idênticas da RAM da máquina virtual contando e comparando a soma de hash das páginas e remove as páginas duplicadas, substituindo-as por links para a mesma página na memória física do servidor. Como resultado, o consumo de memória física é reduzido e algum excesso de assinatura de memória pode ser alcançado com pouca ou nenhuma degradação de desempenho.
Este mecanismo só funciona para páginas de memória de 4 KB (páginas pequenas). O hipervisor nem tenta desduplicar páginas de 2 MB (páginas grandes): a chance de encontrar páginas idênticas desse tamanho não é grande.
Por padrão, o ESXi aloca memória para páginas grandes. A divisão de páginas grandes em páginas pequenas começa quando o limite do estado Alto é atingido e é forçada quando o estado Limpar é atingido (consulte a tabela de estado do hipervisor).
Se você deseja que o TPS comece a funcionar sem esperar que a RAM do host seja preenchida, em Advanced Options ESXi, você precisa definir o valor “Mem.AllocGuestLargePage” para 0 (padrão 1). Em seguida, a alocação de páginas de memória grandes para máquinas virtuais será desativada.
Desde dezembro de 2014, em todas as versões do ESXi, o TPS entre VMs foi desativado por padrão, pois foi encontrada uma vulnerabilidade que teoricamente permite o acesso de uma VM à RAM de outra VM. Detalhes aqui. Não encontrei informações sobre a implementação prática da exploração da vulnerabilidade do TPS.
Política de TPS controlada via opção avançada “Mem.ShareForceSalting” no ESXi:
0 - TPS entre VMs. O TPS funciona para páginas de diferentes VMs;
1 – TPS para VM com o mesmo valor “sched.mem.pshare.salt” no VMX;
2 (padrão) - TPS Intra-VM. O TPS funciona para páginas dentro da VM.
Definitivamente, faz sentido desativar páginas grandes e ativar o Inter-VM TPS em bancos de teste. Também pode ser usado para estandes com grande número do mesmo tipo de VM. Por exemplo, em estandes com VDI, a economia na memória física pode chegar a dezenas de por cento.
balão de memória. Ballooning não é mais uma técnica tão inofensiva e transparente para o sistema operacional da VM quanto o TPS. Mas com aplicação adequada, você pode viver e até trabalhar com Balonismo.
Juntamente com o VMware Tools, um driver especial chamado Balloon Driver (também conhecido como vmmemctl) é instalado na VM. Quando o hipervisor começa a ficar sem memória física e entra no estado Soft, o ESXi solicita que a VM recupere a RAM não utilizada por meio desse driver de balão. O driver, por sua vez, trabalha no nível do sistema operacional e solicita memória livre dele. O hipervisor vê quais páginas de memória física o Driver do balão ocupou, pega a memória da máquina virtual e a devolve ao host. Não há problemas com o funcionamento do SO, pois no nível do SO a memória é ocupada pelo Balloon Driver. Por padrão, o Balloon Driver pode ocupar até 65% da memória da VM.
Se o VMware Tools não estiver instalado na VM ou o Ballooning estiver desabilitado (não recomendo, mas existem :), o hipervisor muda imediatamente para técnicas de remoção de memória mais rigorosas. Conclusão: verifique se o VMware Tools está na VM.
A operação do Balloon Driver pode ser verificada no sistema operacional por meio do VMware Tools.
compressão de memória. Essa técnica é usada quando o ESXi atinge o estado Hard. Como o nome indica, o ESXi tenta reduzir uma página de 4 KB de RAM para 2 KB e, assim, liberar algum espaço na memória física do servidor. Essa técnica aumenta significativamente o tempo de acesso ao conteúdo das páginas RAM da VM, pois a página deve primeiro ser descompactada. Às vezes, nem todas as páginas podem ser compactadas e o processo em si leva algum tempo. Portanto, esta técnica não é muito eficaz na prática.
troca de memória. Após uma curta fase de compactação de memória, o ESXi quase inevitavelmente (se as VMs não tiverem saído para outros hosts ou desligado) mudará para troca. E se houver muito pouca memória restante (estado baixo), o hipervisor também para de alocar páginas de memória para a VM, o que pode causar problemas no sistema operacional convidado da VM.
Veja como funciona a troca. Quando você liga uma máquina virtual, um arquivo com a extensão .vswp é criado para ela. É igual em tamanho à RAM não reservada da VM: é a diferença entre a memória configurada e a reservada. Quando a troca está em execução, o ESXi descarrega as páginas de memória da máquina virtual nesse arquivo e começa a trabalhar com ele em vez da memória física do servidor. É claro que essa memória “operativa” é várias ordens de magnitude mais lenta que a real, mesmo que .vswp esteja no armazenamento rápido.
Ao contrário do balão, quando as páginas não utilizadas são retiradas da VM, com a troca, as páginas que são usadas ativamente pelo sistema operacional ou aplicativos dentro da VM podem ser movidas para o disco. Como resultado, o desempenho da VM cai a ponto de congelar. A VM funciona formalmente e pelo menos pode ser desativada corretamente no sistema operacional. Se você for paciente 😉
Se as VMs foram para Swap, essa é uma situação anormal, que é melhor evitar, se possível.
Principais contadores de desempenho de memória da VM
Então chegamos ao ponto principal. Para monitorar o estado da memória na VM, existem os seguintes contadores:
Ativo — mostra a quantidade de RAM (KB) à qual a VM teve acesso no período de medição anterior.
Uso - o mesmo que Ativo, mas como uma porcentagem da RAM configurada da VM. Calculado usando a seguinte fórmula: ativo ÷ tamanho de memória configurado da máquina virtual.
Alto uso e ativo, respectivamente, nem sempre são um indicador de problemas de desempenho da VM. Se a VM usa memória agressivamente (pelo menos obtém acesso a ela), isso não significa que não há memória suficiente. Em vez disso, é uma ocasião para ver o que está acontecendo no sistema operacional.
Há um alarme de uso de memória padrão para VMs:
Partilhado - a quantidade de VM RAM desduplicada usando TPS (dentro da VM ou entre VMs).
Concedido - a quantidade de memória física do host (KB) fornecida à VM. Inclui Compartilhado.
Consumido (Concedido - Compartilhado) - a quantidade de memória física (KB) que a VM consome do host. Não inclui Compartilhado.
Se parte da memória da VM for fornecida não da memória física do host, mas do arquivo de troca, ou se a memória for retirada da VM por meio do Driver do balão, esse valor não é levado em consideração em Concedido e consumido.
Valores elevados de Concedidos e Consumidos são perfeitamente normais. O sistema operacional retira gradativamente a memória do hipervisor e não a devolve. Com o tempo, em uma VM em execução ativa, os valores desses contadores se aproximam da quantidade de memória configurada e permanecem lá.
zero — a quantidade de VM RAM (KB), que contém zeros. Essa memória é considerada livre pelo hipervisor e pode ser cedida a outras máquinas virtuais. Depois que o sistema operacional convidado escreve algo na memória zerada, ele entra em Consumed e não retorna.
Despesas Reservadas — a quantidade de VM RAM, (KB) reservada pelo hipervisor para a operação da VM. Esta é uma pequena quantidade, mas deve estar disponível no host, caso contrário, a VM não será iniciada.
Balão — a quantidade de RAM (KB) capturada da VM usando o Balloon Driver.
Comprimido - a quantidade de RAM (KB) que foi compactada.
Trocados - a quantidade de RAM (KB) que, por falta de memória física no servidor, foi movida para o disco.
Balões e outros contadores de técnicas de recuperação de memória são zero.
É assim que o gráfico com contadores de memória se parece para uma VM funcionando normalmente com 150 GB de RAM.
No gráfico abaixo, a VM apresenta problemas óbvios. Abaixo do gráfico, você pode ver que para esta VM foram utilizadas todas as técnicas descritas para trabalhar com RAM. Balão para esta VM é muito maior que Consumed. Na verdade, a VM está mais morta do que viva.
ESXTOP
Assim como a CPU, se quisermos avaliar rapidamente a situação do host, bem como sua dinâmica com um intervalo de até 2 segundos, devemos usar o ESXTOP.
A tela ESXTOP por Memória é acessada com a tecla "m" e tem a seguinte aparência (os campos B, D, H, J, K, L, O são selecionados):
Os seguintes parâmetros serão de nosso interesse:
Média de sobrecarga de memória - o valor médio de oversubscription de memória no host por 1, 5 e 15 minutos. Se estiver acima de zero, é uma ocasião para ver o que está acontecendo, mas nem sempre um indicador de problemas.
Nas linhas PMEM/MB и VMKMEM/MB - informações sobre a memória física do servidor e a memória disponível para o VMkernel. Do interessante aqui você pode ver o valor de minfree (em MB), o estado do host na memória (no nosso caso, alto).
Em linha NUMA/MB você pode ver a distribuição de RAM por nós NUMA (soquetes). 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 as técnicas de recuperação de memória:
PSHARE/MB são estatísticas TPS;
TROCAR/MB — Trocar estatísticas de uso;
ZIP/MB — estatísticas de compactação de página de memória;
MEMCTL/MB — Estatísticas de uso do Balloon Driver.
Para VMs individuais, podemos estar interessados nas informações a seguir. Escondi os nomes das VMs para não confundir o público :). Se a métrica ESXTOP for semelhante ao contador no vSphere, forneço o contador correspondente.
MEMSZ — a quantidade de memória configurada na VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + intocado.
GRANT — Concedido ao MB.
TCHD — Ativo em MB.
MCTL? - se o Driver Balloon está instalado na VM.
MCTLSZ — Balão para MB.
MCTLGT — a quantidade de RAM (MB) que o ESXi deseja obter da VM por meio do Balloon Driver (Memctl Target).
MCTLMAX - a quantidade máxima de RAM (MB) que o ESXi pode obter da VM por meio do Driver do balão.
SWCUR — a quantidade atual de RAM (MB) alocada para a VM do arquivo Swap.
SWGT - a quantidade de RAM (MB) que o ESXi deseja fornecer à VM a partir do arquivo Swap (Swap Target).
Além disso, por meio do ESXTOP, você pode ver informações mais detalhadas sobre a topologia NUMA da VM. Para fazer isso, selecione os campos D, G:
NH – nós NUMA nos quais a VM está localizada. Aqui você pode notar imediatamente vm largo, que não cabe em um nó NUMA.
NRMEM - quantos megabytes de memória a VM leva do nó NUMA remoto.
NLMEM - quantos megabytes de memória a VM leva do nó NUMA local.
N%L – porcentagem de memória da VM no nó NUMA local (se for menor que 80%, podem ocorrer problemas de desempenho).
Memória no hipervisor
Se os contadores de CPU para o hipervisor geralmente não são de interesse particular, a situação é inversa com a memória. O alto uso de memória em uma VM nem sempre indica um problema de desempenho, mas o alto uso de memória em um hypervisor aciona técnicas de gerenciamento de memória e causa problemas de desempenho na VM. Os alarmes de uso de memória do host devem ser monitorados para evitar que a VM entre no Swap.
Cancelar troca
Se uma VM estiver em Swap, seu desempenho será bastante reduzido. Traços de balão e compactação desaparecem rapidamente depois que a RAM livre aparece no host, mas a máquina virtual não tem pressa em retornar da troca para a RAM do servidor.
Antes do ESXi 6.0, a única maneira confiável e rápida de tirar uma VM do Swap era reinicializar (para ser mais preciso, desligar/ligar o contêiner). A partir do ESXi 6.0, embora não seja oficial, apareceu uma maneira confiável e funcional de remover uma VM do Swap. Em uma das conferências, pude conversar com um dos engenheiros da VMware encarregados do CPU Scheduler. Ele confirmou que o método é bastante funcional e seguro. Em nossa experiência, também não houve problemas com isso.
Os comandos reais para remover a VM do Swap Duncan Epping. Não vou repetir uma descrição detalhada, apenas dar um exemplo de seu uso. Como você pode ver na captura de tela, algum tempo após a execução dos comandos especificados, o Swap desaparece na VM.
Dicas de gerenciamento de memória ESXi
Por fim, aqui estão algumas dicas que ajudarão a evitar problemas com o desempenho da VM devido à RAM:
- Evite o excesso de assinatura de memória em clusters produtivos. É desejável sempre ter ~ 20-30% de memória livre no cluster para que o DRS (e o administrador) tenha espaço para manobrar e as VMs não entrem no Swap durante a migração. Além disso, não se esqueça da margem de tolerância a falhas. É desagradável quando, quando um servidor falha e a VM é reiniciada usando HA, algumas das máquinas também entram em Swap.
- Em infraestruturas altamente consolidadas, tente NÃO criar VMs com mais da metade da memória do host. Novamente, isso ajudará o DRS a distribuir as máquinas virtuais pelos servidores do cluster sem nenhum problema. Esta regra, claro, não é universal :).
- Observe o alarme de uso da memória do host.
- Não se esqueça de instalar o VMware Tools na VM e não desative o Ballooning.
- Considere habilitar o Inter-VM TPS e desabilitar Large Pages em VDI e ambientes de teste.
- Se a VM estiver com problemas de desempenho, verifique se ela está usando memória de um nó NUMA remoto.
- Tire sua VM do Swap o mais rápido possível! Entre outras coisas, se a VM estiver em Swap, por motivos óbvios, o sistema de armazenamento sofre.
Isso é tudo para mim sobre RAM. Abaixo está um artigo relacionado para aqueles que desejam se aprofundar nos detalhes. O próximo artigo será dedicado a storadzh.
Links úteis
Fonte: habr.com