{"id":35292,"date":"2019-10-31T22:03:28","date_gmt":"2019-10-31T19:03:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory\/"},"modified":"2019-10-31T22:03:28","modified_gmt":"2019-10-31T19:03:28","slug":"analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory","title":{"rendered":"An\u00e1lise de desempenho de VMs no VMware vSphere. Parte 2: Mem\u00f3ria","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"An\u00e1lise
\n
\nParte 1. Sobre o CPU<\/a><\/noindex><\/p>\n

Neste artigo, vamos falar sobre contadores de desempenho da mem\u00f3ria RAM no vSphere.
\nParece que a mem\u00f3ria \u00e9 mais clara do que o processador: se houver problemas de desempenho na VM, \u00e9 dif\u00edcil n\u00e3o notar. Mas, se eles aparecerem, \u00e9 muito mais complicado resolv\u00ea-los. Vamos falar sobre tudo isso. <\/a><\/noindex><\/p>\n

Um pouco de teoria<\/h3>\n

\nA mem\u00f3ria RAM das m\u00e1quinas virtuais vem da mem\u00f3ria do servidor em que as VMs est\u00e3o rodando. Isso \u00e9 bastante \u00f3bvio :). Se a mem\u00f3ria RAM do servidor n\u00e3o for suficiente para todos os que desejam, o ESXi come\u00e7a a aplicar t\u00e9cnicas de otimiza\u00e7\u00e3o do consumo de mem\u00f3ria (memory reclamation techniques). Caso contr\u00e1rio, os sistemas operacionais das VMs falhariam com erros de acesso \u00e0 RAM. <\/p>\n

Quais t\u00e9cnicas o ESXi aplica depende da carga da mem\u00f3ria:<\/p>\n

Estado da mem\u00f3ria<\/b><\/p>\n

Limite<\/b><\/p>\n

A\u00e7\u00f5es<\/b><\/p>\n

Alto<\/p>\n

400% do minFree<\/p>\n

Ap\u00f3s atingir o limite superior, as grandes p\u00e1ginas de mem\u00f3ria s\u00e3o divididas em pequenas (TPS opera no modo padr\u00e3o).<\/p>\n

Limpar<\/p>\n

100% do minFree<\/p>\n

Grandes p\u00e1ginas de mem\u00f3ria s\u00e3o divididas em pequenas, o TPS opera for\u00e7adamente.<\/p>\n

Soft<\/p>\n

64% do minFree<\/p>\n

TPS + Balloon<\/p>\n

Dif\u00edcil<\/p>\n

32% do minFree<\/p>\n

TPS + Compress + Swap<\/p>\n

Baixo<\/p>\n

16% do minFree<\/p>\n

Compress + Swap + Block<\/p>\n

Fonte<\/a><\/noindex> <\/p>\n

minFree \u00e9 a mem\u00f3ria RAM necess\u00e1ria para o funcionamento do hipervisor. <\/p>\n

At\u00e9 o ESXi 4.1 inclu\u00eddo, o minFree era fixo por padr\u00e3o \u2014 6% do volume de RAM do servidor (a porcentagem podia ser alterada pela op\u00e7\u00e3o Mem.MinFreePct no ESXi). Nas vers\u00f5es posteriores, devido ao aumento dos volumes de mem\u00f3ria nos servidores, o minFree passou a ser calculado com base no volume de mem\u00f3ria do host, e n\u00e3o como um valor percentual fixo. <\/p>\n

O valor do minFree (por padr\u00e3o) \u00e9 calculado da seguinte forma:<\/p>\n

Porcentagem de mem\u00f3ria reservada para minFree<\/b><\/p>\n

Faixa de mem\u00f3ria<\/b><\/p>\n

6%<\/p>\n

0-4 GB<\/p>\n

4%<\/p>\n

4-12 GB<\/p>\n

2%<\/p>\n

12-28 GB<\/p>\n

1%<\/p>\n

Mem\u00f3ria restante<\/p>\n

Fonte<\/a><\/noindex><\/p>\n

Por exemplo, para um servidor com 128 GB de RAM, o valor de MinFree seria:
\nMinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
\nO valor real pode diferir por algumas centenas de MB, dependendo do servidor e da mem\u00f3ria RAM.<\/p>\n

Porcentagem de mem\u00f3ria reservada para minFree<\/b><\/p>\n

Faixa de mem\u00f3ria<\/b><\/p>\n

Valor para 128 GB<\/b><\/p>\n

6%<\/p>\n

0-4 GB<\/p>\n

245,76 MB<\/p>\n

4%<\/p>\n

4-12 GB<\/p>\n

327,68 MB<\/p>\n

2%<\/p>\n

12-28 GB<\/p>\n

327,68 MB<\/p>\n

1%<\/p>\n

Mem\u00f3ria restante (100 GB)<\/p>\n

1024 MB<\/p>\n

\nNormalmente, para ambientes produtivos, apenas o estado High pode ser considerado adequado. Para ambientes de teste e desenvolvimento, os estados Clear\/Soft podem ser aceit\u00e1veis. Se a mem\u00f3ria RAM no host estiver abaixo de 64% MinFree, as VMs que operam nele certamente apresentar\u00e3o problemas de desempenho.<\/p>\n

Em cada estado, s\u00e3o aplicadas t\u00e9cnicas espec\u00edficas de recupera\u00e7\u00e3o de mem\u00f3ria, come\u00e7ando pelo TPS, que praticamente n\u00e3o afeta o desempenho das VMs, at\u00e9 o Swapping. Vou explicar mais sobre isso. <\/p>\n

Transparent Page Sharing (TPS).<\/b> TPS \u00e9, grosso modo, a deduplica\u00e7\u00e3o de p\u00e1ginas de mem\u00f3ria RAM de m\u00e1quinas virtuais no servidor.<\/p>\n

O ESXi procura p\u00e1ginas de mem\u00f3ria RAM iguais entre as m\u00e1quinas virtuais, calculando e comparando os hashes das p\u00e1ginas, e remove as duplicatas, substituindo-as por refer\u00eancias \u00e0 mesma p\u00e1gina na mem\u00f3ria f\u00edsica do servidor. Como resultado, o consumo de mem\u00f3ria f\u00edsica \u00e9 reduzido e \u00e9 poss\u00edvel obter um certo overcommitment de mem\u00f3ria praticamente sem perda de desempenho.<\/p>\n

\"An\u00e1lise
\nFonte<\/a><\/noindex><\/p>\n

Este mecanismo funciona apenas para p\u00e1ginas de mem\u00f3ria de 4 KB (small pages). O hipervisor sequer tenta deduplicar p\u00e1ginas de 2 MB (large pages): a probabilidade de encontrar p\u00e1ginas id\u00eanticas desse tamanho n\u00e3o \u00e9 grande.<\/p>\n

Por padr\u00e3o, o ESXi aloca mem\u00f3ria para large pages. A fragmenta\u00e7\u00e3o de large pages em small pages come\u00e7a ao atingir o limiar do estado High e ocorre for\u00e7adamente quando o estado Clear \u00e9 alcan\u00e7ado (veja a tabela de estados do hipervisor).<\/p>\n

Se voc\u00ea deseja que o TPS comece a funcionar sem esperar que a mem\u00f3ria RAM do host fique cheia, nas Op\u00e7\u00f5es Avan\u00e7adas do ESXi \u00e9 necess\u00e1rio definir o valor \u201cMem.AllocGuestLargePage\u201d<\/i> como 0 (por padr\u00e3o 1). Assim, a aloca\u00e7\u00e3o de large pages para m\u00e1quinas virtuais ser\u00e1 desativada.<\/p>\n

Desde dezembro de 2014, em todas as vers\u00f5es do ESXi, o TPS entre VMs est\u00e1 desativado por padr\u00e3o, pois foi descoberta uma vulnerabilidade que teoricamente permite acessar a mem\u00f3ria RAM de outra VM a partir de uma. Mais detalhes aqui. N\u00e3o encontrei informa\u00e7\u00e3o sobre a implementa\u00e7\u00e3o pr\u00e1tica da explora\u00e7\u00e3o da vulnerabilidade TPS.<\/p>\n

A pol\u00edtica de TPS \u00e9 controlada atrav\u00e9s da op\u00e7\u00e3o avan\u00e7ada \u201cMem.ShareForceSalting\u201d<\/i> no ESXi:
\n0 \u2014 Inter-VM TPS. O TPS funciona para p\u00e1ginas de diferentes VMs;
\n1 \u2013 TPS para VMs com o mesmo valor de \u201csched.mem.pshare.salt\u201d no VMX;
\n2 (por padr\u00e3o) \u2013 Intra-VM TPS. O TPS funciona para p\u00e1ginas dentro da VM.<\/p>\n

Definitivamente faz sentido desativar p\u00e1ginas grandes e ativar o Inter-VM TPS em ambientes de teste. Isso tamb\u00e9m pode ser utilizado em ambientes com um grande n\u00famero de VMs id\u00eanticas. Por exemplo, em ambientes com VDI, a economia de mem\u00f3ria f\u00edsica pode alcan\u00e7ar dezenas de porcento. <\/p>\n

Memory Ballooning.<\/b> O Ballooning n\u00e3o \u00e9 mais uma t\u00e9cnica t\u00e3o inofensiva e transparente para o sistema operacional da VM como o TPS. Mas, se aplicado corretamente, \u00e9 poss\u00edvel viver e at\u00e9 trabalhar com o Ballooning.<\/p>\n

Junto com o VMware Tools, \u00e9 instalado na VM um driver especial chamado Balloon Driver (vmmemctl). Quando o hipervisor come\u00e7a a ficar sem mem\u00f3ria f\u00edsica e entra no estado Soft, o ESXi solicita \u00e0 VM que devolva a mem\u00f3ria RAM n\u00e3o utilizada atrav\u00e9s deste Balloon Driver. O driver, por sua vez, atua no n\u00edvel do sistema operacional e solicita mem\u00f3ria livre a ele. O hipervisor v\u00ea quais p\u00e1ginas de mem\u00f3ria f\u00edsica foram ocupadas pelo Balloon Driver, retira a mem\u00f3ria da m\u00e1quina virtual e a devolve ao host. N\u00e3o h\u00e1 problemas no funcionamento do SO, j\u00e1 que no n\u00edvel do SO a mem\u00f3ria est\u00e1 ocupada pelo Balloon Driver. Por padr\u00e3o, o Balloon Driver pode retirar at\u00e9 65% da mem\u00f3ria da VM.<\/p>\n

Se o VMware Tools n\u00e3o estiver instalado na VM ou se o Ballooning estiver desativado (n\u00e3o recomendo, mas existe KB<\/a><\/noindex>:), o hipervisor imediatamente recorre a t\u00e9cnicas mais r\u00edgidas de recupera\u00e7\u00e3o de mem\u00f3ria. Conclus\u00e3o: certifique-se de que o VMware Tools esteja instalado na VM.<\/p>\n

\"An\u00e1lise
\nO funcionamento do Balloon Driver pode ser verificado a partir do SO atrav\u00e9s do VMware Tools.<\/i>.<\/p>\n

Memory Compression.<\/b> Esta t\u00e9cnica \u00e9 aplicada quando o ESXi chega ao estado Hard. Como o pr\u00f3prio nome sugere, o ESXi tenta comprimir as p\u00e1ginas de 4 Kbytes de mem\u00f3ria RAM para 2 Kbytes e, assim, liberar um pouco de espa\u00e7o na mem\u00f3ria f\u00edsica do servidor. Essa t\u00e9cnica aumenta significativamente o tempo de acesso ao conte\u00fado das p\u00e1ginas de mem\u00f3ria da VM, uma vez que a p\u00e1gina precisa ser descomprimida previamente. \u00c0s vezes, nem todas as p\u00e1ginas conseguem ser comprimidas, e o pr\u00f3prio processo leva um certo tempo. Portanto, essa t\u00e9cnica na pr\u00e1tica n\u00e3o \u00e9 muito eficaz.<\/p>\n

Memory Swapping.<\/b> Ap\u00f3s uma breve fase de Memory Compression, o ESXi praticamente inevitavelmente (se as VMs n\u00e3o migraram para outros hosts ou n\u00e3o foram desligadas) passa para o Swapping. E se a mem\u00f3ria restante for muito baixa (estado Low), o hipervisor tamb\u00e9m para de alocar p\u00e1ginas de mem\u00f3ria para as VMs, o que pode causar problemas nos sistemas operacionais convidados das VMs.<\/p>\n

\u00c9 assim que funciona o Swapping. Ao ligar a m\u00e1quina virtual, \u00e9 criado um arquivo com a extens\u00e3o .vswp. O tamanho desse arquivo \u00e9 igual \u00e0 mem\u00f3ria RAM n\u00e3o reservada da MV: \u00e9 a diferen\u00e7a entre a mem\u00f3ria configurada e a mem\u00f3ria reservada. Durante o funcionamento do Swapping, o ESXi descarrega as p\u00e1ginas de mem\u00f3ria da m\u00e1quina virtual para esse arquivo e come\u00e7a a trabalhar com ele em vez da mem\u00f3ria f\u00edsica do servidor. Claro, essa mem\u00f3ria \u201coperacional\u201d \u00e9 significativamente mais lenta do que a verdadeira, mesmo que o .vswp esteja em um armazenamento r\u00e1pido.<\/p>\n

Ao contr\u00e1rio do Ballooning, onde p\u00e1ginas n\u00e3o utilizadas s\u00e3o retiradas da MV, no Swapping, p\u00e1ginas que est\u00e3o ativamente em uso pelo sistema operacional ou aplica\u00e7\u00f5es dentro da MV podem ser transferidas para o disco. Como resultado, o desempenho da MV cai drasticamente, podendo at\u00e9 travar. A MV formalmente continua funcionando e pelo menos pode ser desligada corretamente a partir do sistema operacional. Se voc\u00ea tiver paci\u00eancia \ud83d\ude09<\/p>\n

Se a MV foi para o Swap \u2014 isso \u00e9 uma situa\u00e7\u00e3o an\u00f4mala, que deve ser evitada sempre que poss\u00edvel.<\/p>\n

Principais contadores de desempenho da mem\u00f3ria da m\u00e1quina virtual<\/h3>\n

\nAgora chegamos ao principal. Para monitorar o estado da mem\u00f3ria na MV, existem os seguintes contadores:<\/p>\n

Active<\/b> \u2014 mostra o volume de mem\u00f3ria operacional (KB) ao qual a MV teve acesso no per\u00edodo anterior de medi\u00e7\u00e3o.<\/p>\n

Usage<\/b> \u2014 o mesmo que Active, mas em porcentagem da mem\u00f3ria operacional configurada da MV. \u00c9 calculado pela seguinte f\u00f3rmula: active \u00f7 tamanho da mem\u00f3ria configurada da m\u00e1quina virtual.
\nUm alto Usage e Active, respectivamente, nem sempre s\u00e3o indicadores de problemas de desempenho da MV. Se a MV utiliza agressivamente a mem\u00f3ria (pelo menos, est\u00e1 acessando-a), isso n\u00e3o significa que est\u00e1 sem mem\u00f3ria. \u00c9 mais um motivo para verificar o que est\u00e1 acontecendo no sistema operacional.
\nH\u00e1 um Alarme padr\u00e3o por Uso de Mem\u00f3ria para a MV:<\/p>\n

\"An\u00e1lise
\n
\nCompartilhado<\/b> \u2014 volume de mem\u00f3ria operacional da MV, desduplicada com TPS (dentro da MV ou entre MVs).<\/p>\n

Concedido<\/b> \u2014 volume de mem\u00f3ria f\u00edsica do host (KB) que foi alocada para a MV. Inclui o compartilhado.<\/p>\n

Consumido<\/b> (Concedido \u2014 Compartilhado) \u2014 volume de mem\u00f3ria f\u00edsica (KB) que a MV consome do host. N\u00e3o inclui o compartilhado.<\/p>\n

Se parte da mem\u00f3ria da MV for alocada n\u00e3o da mem\u00f3ria f\u00edsica do host, mas de um arquivo de swap ou a mem\u00f3ria for retirada da MV atrav\u00e9s do Balloon Driver, esse volume n\u00e3o \u00e9 contabilizado em Concedido e Consumido.
\nValores altos de Granted e Consumed s\u00e3o completamente normais. O sistema operacional gradualmente retira mem\u00f3ria do hypervisor e n\u00e3o a devolve. Com o tempo, para uma VM que est\u00e1 em opera\u00e7\u00e3o ativa, os valores desses contadores se aproximam da quantidade de mem\u00f3ria configurada e permanecem l\u00e1.<\/p>\n

Zero<\/b> \u2014 a quantidade de mem\u00f3ria RAM da VM (Kbytes) que cont\u00e9m zeros. Essa mem\u00f3ria \u00e9 considerada livre pelo hypervisor e pode ser alocada para outras m\u00e1quinas virtuais. Ap\u00f3s a guest OS escrever algo na mem\u00f3ria zerada, ela passa para Consumed e n\u00e3o retorna mais.<\/p>\n

Reserved Overhead<\/b> \u2014 a quantidade de mem\u00f3ria RAM da VM (Kbytes) reservada pelo hypervisor para o funcionamento da VM. \u00c9 um pequeno volume, mas deve estar dispon\u00edvel no host; caso contr\u00e1rio, a VM n\u00e3o iniciar\u00e1.<\/p>\n

Balloon<\/b> \u2014 a quantidade de mem\u00f3ria RAM (Kbytes) retirada da VM atrav\u00e9s do Balloon Driver.<\/p>\n

Compressed<\/b> \u2014 a quantidade de mem\u00f3ria RAM (Kbytes) que foi comprimida.<\/p>\n

Swapped<\/b> \u2014 a quantidade de mem\u00f3ria RAM (Kbytes) que, por falta de mem\u00f3ria f\u00edsica no servidor, foi movida para o disco.
\nBalloon e outros contadores de t\u00e9cnicas de recupera\u00e7\u00e3o de mem\u00f3ria s\u00e3o iguais a zero.<\/p>\n

Assim \u00e9 como aparece o gr\u00e1fico com os contadores de uma VM funcionando normalmente com 150 GB de RAM.<\/p>\n

\"An\u00e1lise
\n
\nNo gr\u00e1fico abaixo, a VM apresenta problemas claros. Abaixo do gr\u00e1fico, pode-se ver que todas as t\u00e9cnicas de gerenciamento de mem\u00f3ria foram aplicadas a esta VM. O Balloon para esta VM \u00e9 consideravelmente maior do que o Consumed. Na verdade, a VM est\u00e1 mais morta do que viva. <\/p>\n

\"An\u00e1lise
\n<\/p>\n

ESXTOP<\/h3>\n

\nAssim como com a CPU, se queremos avaliar rapidamente a situa\u00e7\u00e3o no host e sua din\u00e2mica em intervalos de at\u00e9 2 segundos, \u00e9 bom usar o ESXTOP.<\/p>\n

A tela do ESXTOP para Mem\u00f3ria \u00e9 chamada com a tecla 'm' e aparece da seguinte forma (campos B, D, H, J, K, L, O foram selecionados):<\/p>\n

\"An\u00e1lise
\n
\nOs par\u00e2metros interessantes para n\u00f3s ser\u00e3o os seguintes: <\/p>\n

Mem overcommit avg<\/b> \u2014 valor m\u00e9dio de sobrecompromisso de mem\u00f3ria no host por 1, 5 e 15 minutos. Se for maior que zero, \u00e9 um motivo para verificar o que est\u00e1 acontecendo, mas nem sempre indica a presen\u00e7a de problemas.<\/p>\n

Na linha PMEM\/MB<\/b> e VMKMEM\/MB<\/b> \u2014 informa\u00e7\u00f5es sobre a mem\u00f3ria f\u00edsica do servidor e a mem\u00f3ria dispon\u00edvel para o VMkernel. Aqui, podemos ver o valor de minfree (em MB), o estado da mem\u00f3ria do host (neste caso, alto).<\/p>\n

Na linha NUMA\/MB<\/b> pode-se ver a distribui\u00e7\u00e3o da mem\u00f3ria RAM pelos n\u00f3s NUMA (sockets). Neste exemplo, a distribui\u00e7\u00e3o \u00e9 desigual, o que, em princ\u00edpio, n\u00e3o \u00e9 muito bom.<\/p>\n

A seguir, est\u00e3o as estat\u00edsticas gerais do servidor sobre t\u00e9cnicas de recupera\u00e7\u00e3o de mem\u00f3ria:<\/p>\n

PSHARE\/MB<\/b> \u2014 s\u00e3o estat\u00edsticas TPS;<\/p>\n

SWAP\/MB<\/b> \u2014 estat\u00edsticas de uso de Swap;<\/p>\n

ZIP\/MB<\/b> \u2014 estat\u00edsticas de compress\u00e3o de p\u00e1ginas de mem\u00f3ria;<\/p>\n

MEMCTL\/MB<\/b> \u2014 estat\u00edsticas de utiliza\u00e7\u00e3o do Balloon Driver.<\/p>\n

Para m\u00e1quinas virtuais individuais, podemos nos interessar pelas seguintes informa\u00e7\u00f5es. Os nomes das VMs foram ocultados para n\u00e3o confundir o p\u00fablico:). Se a m\u00e9trica ESXTOP for semelhante ao contador no vSphere, trago o contador correspondente. <\/p>\n

MEMSZ<\/b> \u2014 volume de mem\u00f3ria configurado na VM (MB).
\nMEMSZ = GRANT + MCTLSZ + SWCUR + untouched.<\/p>\n

GRANT<\/b> \u2014 Granted em MB.<\/p>\n

TCHD<\/b> \u2014 Active em MB.<\/p>\n

MCTL?<\/b> \u2014 se o Balloon Driver est\u00e1 instalado na VM.<\/p>\n

MCTLSZ<\/b> \u2014 Balloon em MB.<\/p>\n

MCTLGT<\/b> \u2014 volume de mem\u00f3ria RAM (MB) que o ESXi deseja retirar da VM atrav\u00e9s do Balloon Driver (Memctl Target).<\/p>\n

MCTLMAX<\/b> \u2014 volume m\u00e1ximo de mem\u00f3ria RAM (MB) que o ESXi pode retirar da VM atrav\u00e9s do Balloon Driver.<\/p>\n

SWCUR<\/b> \u2014 volume atual de mem\u00f3ria RAM (MB) alocado \u00e0 VM a partir do arquivo Swap. <\/p>\n

SWGT<\/b> \u2014 volume de mem\u00f3ria RAM (MB) que o ESXi deseja alocar \u00e0 VM a partir do arquivo Swap (Swap Target).<\/p>\n

Atrav\u00e9s do ESXTOP, tamb\u00e9m \u00e9 poss\u00edvel ver informa\u00e7\u00f5es mais detalhadas sobre a topologia NUMA da VM. Para isso, \u00e9 necess\u00e1rio selecionar os campos D,G:<\/p>\n

\"An\u00e1lise
\n
\nNHN<\/b> \u2013 N\u00f3s NUMA nos quais a VM est\u00e1 localizada. Aqui, podemos imediatamente notar VMs amplas que n\u00e3o cabem em um \u00fanico n\u00f3 NUMA.<\/p>\n

NRMEM<\/b> \u2013 quantos megabytes de mem\u00f3ria a VM est\u00e1 retirando de um n\u00f3 NUMA remoto.<\/p>\n

NLMEM<\/b> \u2013 quantos megabytes de mem\u00f3ria a VM est\u00e1 retirando de um n\u00f3 NUMA local.<\/p>\n

N%L<\/b> \u2013 porcentagem de mem\u00f3ria da VM no n\u00f3 NUMA local (se menos de 80% \u2014 podem surgir problemas de desempenho).<\/p>\n

Mem\u00f3ria no hipervisor<\/h3>\n

\nSe os contadores de CPU do hipervisor geralmente n\u00e3o s\u00e3o de interesse especial, a situa\u00e7\u00e3o \u00e9 oposta com a mem\u00f3ria. Um alto uso de mem\u00f3ria na VM nem sempre indica um problema de desempenho, mas um alto uso de mem\u00f3ria no hipervisor definitivamente inicia as t\u00e9cnicas de gerenciamento de mem\u00f3ria e causa problemas de desempenho na VM. Devemos monitorar os alarmes de uso de mem\u00f3ria do host e evitar que a VM entre em Swap.<\/p>\n

\"An\u00e1lise
\n
\n\"An\u00e1lise
\n<\/p>\n

Unswap<\/h3>\n

\nSe a VM entrar em Swap, seu desempenho diminui significativamente. Os vest\u00edgios de Ballooning e compress\u00e3o desaparecem rapidamente ap\u00f3s a chegada de mem\u00f3ria RAM livre no host, mas a m\u00e1quina virtual n\u00e3o se apressa a voltar do Swap para a mem\u00f3ria RAM do servidor.
\nAt\u00e9 a vers\u00e3o ESXi 6.0, a \u00fanica maneira confi\u00e1vel e r\u00e1pida de tirar uma VM do Swap era reiniciar (mais especificamente, desligar\/ligar o cont\u00eainer). A partir do ESXi 6.0, surgiu um m\u00e9todo que, embora n\u00e3o oficialmente reconhecido, \u00e9 funcional e seguro para remover VMs do Swap. Em uma das confer\u00eancias, conversei com um dos engenheiros da VMware que trabalha no CPU Scheduler. Ele confirmou que o m\u00e9todo \u00e9 totalmente funcional e seguro. Em nossa experi\u00eancia, n\u00e3o tivemos problemas com isso.<\/p>\n

Comandos para tirar VMs do Swap descreveu<\/a><\/noindex> Duncan Epping. N\u00e3o vou repetir a descri\u00e7\u00e3o detalhada, apenas vou dar um exemplo de uso. Como pode ser visto na captura de tela, algum tempo ap\u00f3s a execu\u00e7\u00e3o do comando fornecido, o Swap na VM desaparece.<\/p>\n

\"An\u00e1lise
\n<\/p>\n

Dicas para gerenciar a mem\u00f3ria RAM no ESXi<\/h3>\n

\nPor fim, aqui est\u00e3o algumas dicas que podem ajud\u00e1-lo a evitar problemas de desempenho em VMs causados pela mem\u00f3ria RAM:<\/p>\n