Após conhecermos os comandos básicos da ferramenta ESXTOP na parte 1 e analisado a CPU na parte 2, chegou a hora de analisarmos a memória, seguindo a linha das postagens anteriores, iremos utilizar a ferramenta ESXTOP na visão memória.

Antes da parte prática, um resumo básico sobre o gerenciamento de memória efetuado pelo o Kernel do ESXi (VMKernel), este componente é responsável por efetuar toda a abstração e alocação dinâmica de memória para as máquinas virtuais ativas. Como a memória é um recurso finito, o VMKernel utiliza algumas técnicas de gerenciamento e reclamação de memória com o objetivo de maximizar a disponibilidade de memória livre e a performance de uma forma geral. Na ordem de utilização temos quatro técnicas:

1 – TPS

Por padrão o VMKernel faz uso de um recurso denominado TPS (Transparent Page Sharing), que na prática procura por páginas semelhantes na memória (toda a memória física do host) e excluí páginas duplicadas de forma muito semelhante ao conceito de de-duplicação (as páginas duplicadas são excluídas e em seu lugar apenas uma referência para uma única página é criada eliminando as duplicadas).  Este recurso é utilizado durante todo o tempo, independente da quantidade de memória livre no servidor físico.

2 – Ballooning

Em momentos de contenção de memória ou sobre utilização (“overcommitment”), o VMKernel utiliza-se do recurso denominado “Ballooning”, como o VMKernel não tem controle sobre o gerenciamento de memória realizado pelo sistema operacional da máquina virtual, é necessário que a máquina virtual possua o “Balloon Driver” (presente no VMTools e oficialmente nomeado como VMware Memory Control Driver – vmmemctl). Este mecanismo consiste do seguinte comportamento: Quando o sistema operacional visitante requer páginas de memória, as mesmas são mapeadas na memória física, quando o sistema operacional visitante não necessita mais daquelas páginas, não ocorre a liberação das mesmas, logo o “Balloon Driver” funciona como um balão. Quando necessário esse balão “enche”, requisitando do sistema operacional visitante páginas de memória (basicamente as paginas não mais necessárias que não foram liberadas na memória física), com isso é possível reclamar a memória não mais usada pelo sistema operacional da máquina virtual com o mínimo de impacto possível na performance.

3 – Memory Compression

Como o nome sugere, essa técnica introduzida no VSphere 4.1, consiste da compressão das páginas em memória, este recurso só é utilizado em casos de elevada contenção de memória.

4 – Memory Swapping

Em situações extremas, o recurso “Memory Swapping” (troca de páginas entre memória e disco, também conhecido como paginação em disco) entra em ação gerando um impacto muito significativo na performance, neste caso as páginas de memória menos utilizadas são gravadas no disco.

Agora que possuímos um entendimento elementar do gerenciamento de memória, estamos prontos para iniciarmos nosso estudo prático. Após conectarmos ao host ESXi via SSH e invocarmos o ESXTOP através do comando “esxtop”, necessitamos alternar para a visão memória, para isso, basta pressionarmos a tecla “m”.

Primeiramente vamos entender as informações úteis exibidas no cabeçalho (Figura 1), a primeira linha do cabeçalho contém o horário local (UTC), o “uptime” do host ESXi, na sequencia a quantidade de “worlds”, número de máquinas virtuais em execução, quantidade total de vCPUs e média de sobre utilização da memória (três valores representando as médias do último minuto, cinco e quinze minutos). A sobre utilização (“overcommitment”) significa que as máquinas virtuais estão utilizando uma quantidade de memória superior à memória física disponível no host.  Ainda no cabeçalho temos a quantidade de memória física total (PMEM) em MB, e a memória física em uso pelo VMKernel (vmk), por outros componentes (other) e livre (free), na linha seguinte (VMKMEM) informações do gerenciamento de memória do VMKernel com valores reservados para “resource pools” (rsvd).

Na quarta linha (de cima para baixo) do cabeçalho temos a informação da topologia NUMA, neste caso temos dois nós NUMA (um nó para cada processador). Nas linhas seguintes temos informações do TPS (PSHARE), “Memory Swapping” (SWAP), compressão de memória (ZIP) e a quantidade de memória reclamada via “Ballooning” (MEMCTL).

Para maior assertividade, iremos pressionar a tecla “f” e selecionar os campos desejados pressionando as teclas “A”, “D”, “J”, “K” e “Q”, de modo que teremos os campos selecionados de forma semelhante a Figura 2.

Agora vamos entender o significado dos campos (Figura 3):

MCTL?, Para este campo temos duas informações possíveis o “Y” que representa a presença do “vmmemctl” (“Balloon Driver”) na máquina virtual, em caso de ausência este valor será “N”.

MCTLSZ, representa a quantidade de memória física reclamada pelo “Balloon Driver”, qualquer valor diferente de zero indica sobre utilização de memória.

SWCUR, representa a quantidade de memória (em MB), paginada em disco. Valores diferentes de zero indicam sobre utilização de memória. Nesse caso a degradação de performance tende a ser muito elevada.

SWR/s e SWW/s, indicam a taxa de leituras e escritas em disco, valores diferentes de zero indicam paginação em disco.

CACHEUSD, ZIP/s e UNZIP/s, estão relacionados com a compressão de memória, em situação normal todos devem estar com valor zero, quaisquer valores diferentes de zero nestes campos indicam que o “host” está efetuando compressão de memória, ou seja, está enfrentando contenção de memória.

Basicamente, a nossa análise até aqui considerou cenários de contenção de memória, agora, vamos alternar os campos novamente pressionando a tecla “f” e pressionando as teclas “B”, “D” e “G” selecionaremos as estatísticas “NUMA”, a tela de seleção de campos deverá se assemelhar a presente na Figura 4.

De forma sucinta a arquitetura NUMA (Non Uniform Memory Access) consiste em uma organização de memória onde cada processador possui sua memória local, esta arquitetura é uma evolução das arquiteturas multiprocessador anteriores, onde a memória era uniforme e acessada por vários processadores ao mesmo tempo. Esse acesso uniforme gerava alguns problemas indesejáveis, como questões relacionadas à coerência de “CACHE” e a contenção ao acesso simultâneo a memória. Com a introdução da arquitetura NUMA cada processador acessa sua memória local com baixa latência e em alguns casos a memória do outro processador pode ser acessada com uma latência maior (não uniforme). Para nossa análise é desejável que todas as máquinas virtuais executem na memória local, para facilitar a compreensão, imaginemos uma máquina virtual executando SQL Server e configurada com 96 GB de memória RAM em um servidor com 128 GB de RAM e com dois processadores, neste exemplo teremos dois nós NUMA (um nó para cada processador) com 64 GB de memória física cada. Desta forma em alguns momentos a máquina virtual necessitará acessar a memória remota, pois o tamanho da memória configurada excede a capacidade de um único nó NUMA, o SQL Server por padrão irá alocar praticamente toda a memória atribuída à máquina virtual.

Agora vamos analisar os campos apresentados na Figura 5:

NMN, representa qual nó numa NUMA a máquina virtual (ou o “world”) está localizada.

NLMEM, representa a memória em MB que está localizada no nó NUMA local.

NRMEM, representa a memória em MB que está localizada no nó NUMA remoto.

N%L, representa o percentual da memória que está alocado localmente, se este valor for inferior a 85% você enfrentará severos problemas de performance.

Finalmente concluímos esta parte, na próxima iremos analisar algumas métricas relacionadas ao disco.

ANÁLISE DE PERFORMANCE VMWARE – PARTE 1

ANÁLISE DE PERFORMANCE VMWARE – PARTE 2