Neste artigo falaremos dos contadores de rendemento da memoria de acceso aleatorio (RAM) en vSphere.
Parece que coa memoria todo está máis claro que co procesador: se xorden problemas de rendemento nunha máquina virtual, é difícil non notalos. Pero se aparecen, é moito máis difícil tratar con eles. Pero primeiro o primeiro.
Un pouco de teoría
A RAM das máquinas virtuais tómase da memoria do servidor no que se executan as máquinas virtuales. Isto é bastante obvio :). Se a memoria RAM do servidor non é suficiente para todos, ESXi comeza a utilizar técnicas de recuperación de memoria. En caso contrario, os sistemas operativos da VM fallarían con erros de acceso á RAM.
ESXi decide que técnicas usar dependendo da carga da RAM:
Estado da memoria
Fronteira
Actividade
Alto
400% de minGratuito
Despois de alcanzar o límite superior, as páxinas de memoria grandes divídense en pequenas (TPS funciona en modo estándar).
claro
100% de minGratuito
As páxinas de memoria grandes divídense en pequenas, o TPS é forzado.
Brando
64% de minGratuito
TPS + Globo
Difícil
32% de minGratuito
TPS + Comprimir + Intercambiar
Baixo
16% de minGratuito
Comprimir + Intercambiar + Bloquear
minFree é a RAM necesaria para que o hipervisor funcione.
Ata ESXi 4.1 incluído, minFree corrixiuse de forma predeterminada: o 6% da RAM do servidor (a porcentaxe podía cambiarse mediante a opción Mem.MinFreePct en ESXi). Nas versións posteriores, debido ao crecemento da memoria nos servidores, minFree comezou a calcularse en función da cantidade de memoria do servidor, e non como un valor porcentual fixo.
O valor minFree (predeterminado) calcúlase do seguinte xeito:
Porcentaxe de memoria reservada para minFree
Rango de memoria
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Memoria restante
Por exemplo, para un servidor con 128 GB de RAM, o valor de MinFree será o seguinte:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
O valor real pode diferir nun par de centos de MB, dependendo do servidor e da memoria RAM.
Porcentaxe de memoria reservada para minFree
Rango de memoria
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%
Memoria restante (100 GB)
1024 MB
Normalmente, para stands produtivos, só o estado Alto pode considerarse normal. Para bancos de probas e desenvolvemento, os estados claros/suaves poden ser aceptables. Se a memoria RAM do host é inferior ao 64% MinFree, as máquinas virtuales que se executan nel definitivamente teñen problemas de rendemento.
En cada estado, utilízanse certas técnicas de recuperación de memoria, a partir de TPS, que practicamente non ten ningún efecto no rendemento da máquina virtual, ata o intercambio. Vouvos contar máis deles.
Compartir páxinas transparentes (TPS). TPS é, grosso modo, a deduplicación de páxinas RAM das máquinas virtuais do servidor.
ESXi busca páxinas de memoria RAM de máquina virtual idénticas contando e comparando a suma hash das páxinas, e elimina as páxinas duplicadas, substituíndoas por referencias á mesma páxina na memoria física do servidor. Como resultado, o consumo de memoria física redúcese e pódese conseguir unha subscrición excesiva de memoria sen practicamente ningún impacto no rendemento.
Este mecanismo só funciona para páxinas de memoria de 4 KB de tamaño (páxinas pequenas). O hipervisor nin sequera tenta deduplicar páxinas de 2 MB de tamaño (páxinas grandes): a posibilidade de atopar páxinas idénticas deste tamaño non é grande.
Por defecto, ESXi asigna memoria a páxinas grandes. A división de páxinas grandes en páxinas pequenas comeza cando se alcanza o limiar de estado Alto e é forzada cando se alcanza o estado Borrar (consulta a táboa de estados do hipervisor).
Se queres que TPS comece a funcionar sen esperar a que a RAM do host estea chea, debes establecer o valor en Opcións avanzadas ESXi "Mem.AllocGuestLargePage" a 0 (por defecto 1). A continuación, desactivarase a asignación de páxinas de memoria grande para máquinas virtuais.
Desde decembro de 2014, en todas as versións de ESXi, o TPS entre máquinas virtuales está desactivado por defecto, xa que se atopou unha vulnerabilidade que teoricamente permite que unha máquina virtual acceda á memoria RAM doutra máquina virtual. Detalles aquí. Non atopei información sobre a implementación práctica da explotación da vulnerabilidade TPS.
A política de TPS contrólase mediante unha opción avanzada "Mem.ShareForceSalting" en ESXi:
0 - TPS Inter-VM. TPS funciona para páxinas de diferentes máquinas virtuales;
1 - TPS para máquinas virtuales co mesmo valor "sched.mem.pshare.salt" en VMX;
2 (predeterminado) – TPS intra-VM. TPS funciona para páxinas dentro dunha máquina virtual.
Definitivamente ten sentido desactivar páxinas grandes e habilitar TPS Inter-VM nos bancos de proba. Isto tamén se pode usar para stands cunha gran cantidade de máquinas virtuales similares. Por exemplo, en stands con VDI, o aforro na memoria física pode chegar a decenas de por cento.
Globo de memoria. Os globos xa non son unha técnica tan inofensiva e transparente para o sistema operativo VM como TPS. Pero se se usa correctamente, podes vivir e mesmo traballar con Globo.
Xunto con Vmware Tools, instálase na máquina virtual un controlador especial chamado Balloon Driver (tamén coñecido como vmmemctl). Cando o hipervisor comeza a quedar sen memoria física e entra no estado Soft, ESXi pídelle á máquina virtual que recupere a RAM non utilizada a través deste controlador de globo. O controlador, pola súa banda, funciona a nivel de sistema operativo e pídelle memoria libre. O hipervisor ve que páxinas de memoria física ocupou o controlador de globo, toma memoria da máquina virtual e devólvaa ao host. Non hai problemas co funcionamento do SO, xa que a nivel do SO a memoria está ocupada polo controlador de globo. De forma predeterminada, o controlador de globo pode ocupar ata o 65 % da memoria da máquina virtual.
Se VMware Tools non está instalado na máquina virtual ou se desactiva o globo (non o recomendo, pero hai :), o hipervisor cambia inmediatamente a técnicas máis estritas para eliminar memoria. Conclusión: asegúrese de que VMware Tools estea na máquina virtual.
O funcionamento de Balloon Driver pódese comprobar desde o sistema operativo a través de VMware Tools.
Compresión de memoria. Esta técnica úsase cando ESXi alcanza o estado Hard. Como o nome indica, ESXi tenta comprimir unha páxina de 4 KB de RAM en 2 KB, liberando así espazo na memoria física do servidor. Esta técnica aumenta significativamente o tempo de acceso ao contido das páxinas da RAM da VM, xa que primeiro debe descomprimirse a páxina. Ás veces non se poden comprimir todas as páxinas e o proceso en si leva algún tempo. Polo tanto, esta técnica non é moi eficaz na práctica.
Intercambio de memoria. Despois dunha breve fase de compresión de memoria, ESXi case inevitablemente (se as máquinas virtuales non se moveron a outros anfitrións ou non están desactivadas) cambia a Intercambiar. E se queda moi pouca memoria (estado baixo), o hipervisor tamén deixa de asignar páxinas de memoria á máquina virtual, o que pode causar problemas no sistema operativo convidado da máquina virtual.
Así funciona o intercambio. Cando acendes unha máquina virtual, créase para ela un ficheiro cunha extensión .vswp. É igual en tamaño á memoria RAM sen reserva da máquina virtual: esta é a diferenza entre a memoria configurada e a reservada. Cando o intercambio está a executarse, ESXi intercambia páxinas de memoria da máquina virtual neste ficheiro e comeza a traballar con el en lugar da memoria física do servidor. Por suposto, esa memoria "RAM" é varias ordes de magnitude máis lenta que a memoria real, aínda que o .vswp estea en almacenamento rápido.
A diferenza de Ballooning, cando as páxinas non utilizadas son tomadas dunha máquina virtual, con Swapping as páxinas que son utilizadas activamente polo SO ou as aplicacións dentro da máquina virtual pódense mover ao disco. Como resultado, o rendemento da VM cae ata o punto de conxelarse. A máquina virtual está funcionando formalmente e, como mínimo, pódese desactivar correctamente desde o sistema operativo. Se es paciente 😉
Se as máquinas virtuales pasaron a Intercambiar, esta é unha situación de emerxencia que é mellor evitar se é posible.
Contadores básicos de rendemento da memoria da máquina virtual
Entón chegamos ao principal. Para supervisar o estado da memoria da máquina virtual, hai os seguintes contadores:
Activo — mostra a cantidade de RAM (KB) á que accedeu a máquina virtual no período de medición anterior.
Uso — o mesmo que Activo, pero como porcentaxe da RAM configurada da máquina virtual. Calcúlase mediante a seguinte fórmula: activo ÷ tamaño de memoria configurado da máquina virtual.
Uso alto e Activo, respectivamente, non sempre son un indicador de problemas de rendemento da máquina virtual. Se a máquina virtual está a usar a memoria de forma agresiva (polo menos accedendo a ela), isto non significa que non haxa memoria suficiente. Pola contra, esta é unha razón para mirar o que está a suceder no sistema operativo.
Hai unha alarma estándar para o uso da memoria para máquinas virtuales:
Compartido — a cantidade de RAM da máquina virtual desduplicada mediante TPS (dentro dunha máquina virtual ou entre máquinas virtuales).
Concedida — a cantidade de memoria física do host (KB) que se asignou á máquina virtual. Habilita Compartido.
Consumido (Concedido - Compartido): a cantidade de memoria física (KB) que consume a máquina virtual do host. Non inclúe Compartido.
Se parte da memoria da máquina virtual non se dá da memoria física do host, senón dun ficheiro de intercambio, ou se toma memoria da máquina virtual a través do controlador de globo, esta cantidade non se ten en conta en Concedido e Consumido.
Os altos valores concedidos e consumidos son completamente normais. O sistema operativo toma gradualmente memoria do hipervisor e non a devolve. Co paso do tempo, nunha máquina virtual en execución activa, os valores destes contadores achéganse á cantidade de memoria configurada e permanecen alí.
Cero — a cantidade de RAM de VM (KB), que contén ceros. Tal memoria considérase libre polo hipervisor e pódese ceder a outras máquinas virtuais. Despois de que o sistema operativo convidado escribiu algo na memoria posta a cero, entra en Consumed e non regresa.
Sobrecarga reservada — a cantidade de RAM da máquina virtual (KB) reservada polo hipervisor para o funcionamento da máquina virtual. Esta é unha cantidade pequena, pero debe estar dispoñible no host, se non, a máquina virtual non se iniciará.
Globo — a cantidade de RAM (KB) eliminada da máquina virtual mediante o controlador de globo.
Comprimido — a cantidade de RAM (KB) que foi comprimida.
Intercambiado — a cantidade de RAM (KB), que, debido á falta de memoria física no servidor, trasladouse ao disco.
Os contadores de globos e outras técnicas de recuperación de memoria son cero.
Así se ve o gráfico cos contadores de memoria dunha máquina virtual que funciona normalmente con 150 GB de RAM.
No gráfico seguinte, a VM ten problemas obvios. Debaixo do gráfico podes ver que para esta máquina virtual utilizáronse todas as técnicas descritas para traballar con RAM. O globo para esta máquina virtual é moito máis grande que Consumed. De feito, VM está máis morto que vivo.
ESXTOP
Do mesmo xeito que coa CPU, se queremos avaliar rapidamente a situación do host, así como a súa dinámica cun intervalo de ata 2 segundos, deberíamos usar ESXTOP.
A pantalla Memoria ESXTOP chámase coa tecla "m" e ten o seguinte aspecto (campos B,D,H,J,K,L,O seleccionados):
Os seguintes parámetros serán de interese para nós:
Mem overcommit avg — valor medio da sobresubscrición de memoria no servidor durante 1, 5 e 15 minutos. Se está por riba de cero, entón este é un motivo para mirar o que está a suceder, pero non sempre un indicador de problemas.
En liñas PMEM/MB и VMKMEM/MB — información sobre a memoria física do servidor e a memoria dispoñible para o VMkernel. Entre as cousas interesantes aquí podes ver o valor minfree (en MB), o estado do host na memoria (no noso caso, alto).
En liña NUMA/MB podes ver a distribución da memoria RAM entre nós (sockets) NUMA. Neste exemplo, a distribución é desigual, o que en principio non é moi bo.
As seguintes son as estatísticas xerais do servidor para as técnicas de recuperación de memoria:
PSHARE/MB — Estas son as estatísticas de TPS;
SWAP/MB — Intercambiar estatísticas de uso;
ZIP/MB — estatísticas de compresión da páxina de memoria;
MEMCTL/MB — Estatísticas de uso de Balloon Driver.
Para máquinas virtuales individuais, é posible que esteamos interesados na seguinte información. Ocultei os nomes das máquinas virtuales para non confundir ao público :). Se a métrica ESXTOP é similar ao contador de vSphere, proporcionarei o contador correspondente.
MEMSZ — cantidade de memoria configurada na máquina virtual (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + sen tocar.
SUBVENCIÓN - Concedido en MB.
TCHD - Activo en MB.
MCTL? — se o controlador de globo está instalado na máquina virtual.
MCTLSZ - Globo para MB.
MCTLGT — a cantidade de RAM (MBytes) que ESXi quere eliminar da máquina virtual a través do controlador de globo (Memctl Target).
MCTLMAX — a cantidade máxima de RAM (MBytes) que ESXi pode eliminar dunha máquina virtual a través do controlador de globo.
SWCUR — a cantidade actual de RAM (MBytes) asignada á máquina virtual desde o ficheiro de intercambio.
S.W.G.T. — a cantidade de RAM (MBytes) que ESXi quere darlle á máquina virtual desde o ficheiro de intercambio (destino de intercambio).
Tamén pode ver información máis detallada sobre a topoloxía NUMA da máquina virtual a través de ESXTOP. Para iso, seleccione os campos D, G:
PEQUENO – Nodos NUMA nos que se atopa a máquina virtual. Aquí podes notar inmediatamente vm ampla, que non cabe nun nodo NUMA.
NRMEM – cantos megabytes de memoria toma a máquina virtual do nodo NUMA remoto.
NLMEM – cantos megabytes de memoria toma a máquina virtual do nodo NUMA local.
N% L – porcentaxe de memoria de VM no nodo NUMA local (se é inferior ao 80 %, poden xurdir problemas de rendemento).
Memoria no hipervisor
Se os contadores de CPU para un hipervisor adoitan non ser de especial interese, entón coa memoria a situación é a contraria. O uso elevado de memoria nunha máquina virtual non sempre indica un problema de rendemento, pero o uso elevado de memoria nun hipervisor desencadea técnicas de xestión da memoria e provoca problemas co rendemento da máquina virtual. Debe supervisar as alarmas de uso da memoria do host e evitar que as máquinas virtuales entren en Swap.
Desintercambiar
Se unha máquina virtual queda atrapada no intercambio, o seu rendemento redúcese moito. Os rastros de ballooning e compresión desaparecen rapidamente despois de que a memoria RAM libre aparece no host, pero a máquina virtual non ten présa por volver de Swap á RAM do servidor.
Antes de ESXi 6.0, a única forma fiable e rápida de eliminar unha máquina virtual de Swap era reiniciar (máis precisamente, apagar/encender o contedor). A partir de ESXi 6.0, aínda que non é totalmente oficial, apareceu un xeito fiable e eficaz de eliminar unha máquina virtual de Swap. Nunha das conferencias, puiden falar cun dos enxeñeiros de VMware responsables de CPU Scheduler. Confirmou que o método funciona bastante e é seguro. Segundo a nosa experiencia, tampouco houbo problemas con el.
Os comandos reais para eliminar unha máquina virtual de Swap Duncan Epping. Non vou repetir a descrición detallada, só poñerei un exemplo do seu uso. Como podes ver na captura de pantalla, un tempo despois de executar o comando especificado, Swap na VM desaparece.
Consellos para xestionar a RAM en ESXi
Finalmente, aquí tes algúns consellos que che axudarán a evitar problemas co rendemento da VM debido á memoria RAM:
- Evite a subscrición excesiva de RAM nos clústeres produtivos. É recomendable ter sempre ~ 20-30% de memoria libre no clúster para que DRS (e o administrador) teñan marxe de manobra e as máquinas virtuales non vaian a Swap durante a migración. Ademais, non se esqueza da marxe de tolerancia a fallos. É desagradable cando, cando un servidor falla e a máquina virtual se reinicia usando HA, algunhas das máquinas tamén van a Intercambiar.
- En infraestruturas moi consolidadas, intente NON crear máquinas virtuales con memoria superior á metade da memoria do host. Isto de novo axudará a DRS a distribuír máquinas virtuais entre servidores de clúster sen ningún problema. Esta regra, por suposto, non é universal :).
- Coidado coa alarma de uso da memoria do host.
- Non esquezas instalar VMware Tools na máquina virtual e non desactives os globos.
- Considere habilitar TPS entre máquinas virtuales e desactivar Páxinas grandes en ambientes de proba e VDI.
- Se a máquina virtual está experimentando problemas de rendemento, comprobe se está a usar memoria dun nodo NUMA remoto.
- Elimina máquinas virtuales de Swap o máis rápido posible! Entre outras cousas, se a VM está en Swap, o sistema de almacenamento sofre por razóns obvias.
Iso é todo para min sobre a RAM. Abaixo amósanse artigos relacionados para aqueles que queiran profundizar. O seguinte artigo estará dedicado ao almacenamento.
Ligazóns útiles
Fonte: www.habr.com