En este artículo, hablaremos sobre los contadores de rendimiento de la memoria de acceso aleatorio (RAM) en vSphere.
Parece que con la memoria todo es más claro que con el procesador: si una VM tiene problemas de rendimiento, es difícil no notarlo. Pero si aparecen, es mucho más difícil tratar con ellos. Pero primero lo primero.
Un poco de teoría
La RAM de las máquinas virtuales se toma de la memoria del servidor en el que se ejecutan las máquinas virtuales. Es bastante obvio :). Si la RAM del servidor no es suficiente para todos, ESXi comienza a utilizar técnicas de recuperación de memoria para optimizar el consumo de RAM. De lo contrario, los sistemas operativos de las VM fallarían con errores de acceso a la RAM.
Qué técnicas usar ESXi decide según la carga de RAM:
Estado de la memoria
Frontera
Actividad
Alta
400% de minGratis
Después de alcanzar el límite superior, las páginas de memoria grandes se dividen en pequeñas (TPS funciona en modo estándar).
Actualizar
100% de minGratis
Las páginas de memoria grandes se dividen en pequeñas, TPS se ve obligado a trabajar.
Soft
64% de minGratis
TPS + Globo
Difícil
32% de minGratis
TPS + Comprimir + Intercambiar
Baja
16% de minGratis
Comprimir + Intercambiar + Bloquear
minFree es la memoria RAM necesaria para que funcione el hipervisor.
Antes de ESXi 4.1 inclusive, minFree se solucionó de manera predeterminada: 6 % de la RAM del servidor (el porcentaje se podía cambiar a través de la opción Mem.MinFreePct en ESXi). En versiones posteriores, debido al aumento en el tamaño de la memoria en los servidores, minFree comenzó a calcularse en función de la cantidad de memoria del host, y no como un porcentaje fijo.
El valor minFree (predeterminado) se calcula de la siguiente manera:
Porcentaje de memoria reservada para minFree
Rango de memoria
6%
0-4GB
4%
4-12GB
2%
12-28GB
1%
Memoria restante
Por ejemplo, para un servidor con 128 GB de RAM, el valor de MinFree sería:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
El valor real puede diferir en un par de cientos de MB, depende del servidor y la memoria RAM.
Porcentaje de memoria reservada para minFree
Rango de memoria
Valor por 128 GB
6%
0-4GB
245,76 MB
4%
4-12GB
327,68 MB
2%
12-28GB
327,68 MB
1%
Memoria restante (100 GB)
1024 MB
Por lo general, para rodales productivos, solo el estado Alto puede considerarse normal. Para bancos de prueba y desarrollo, los estados Clear/Soft pueden ser aceptables. Si la memoria RAM en el host es inferior al 64 % de MinFree, entonces las máquinas virtuales que se ejecutan definitivamente tienen problemas de rendimiento.
En cada estado se aplican determinadas técnicas de recuperación de memoria, empezando por TPS, que prácticamente no afecta al rendimiento de la VM, y finalizando con Swapping. Te cuento más sobre ellos.
Uso compartido de página transparente (TPS). TPS es, en términos generales, deduplicación de páginas de memoria de máquinas virtuales en un servidor.
ESXi busca páginas idénticas de RAM de máquina virtual contando y comparando la suma de hash de las páginas, y elimina las páginas duplicadas, reemplazándolas con enlaces a la misma página en la memoria física del servidor. Como resultado, se reduce el consumo de memoria física y se puede lograr cierta sobresuscripción de memoria con poca o ninguna degradación del rendimiento.
Este mecanismo solo funciona para páginas de memoria de 4 KB (páginas pequeñas). El hipervisor ni siquiera intenta deduplicar páginas de 2 MB (páginas grandes): la posibilidad de encontrar páginas idénticas de este tamaño no es muy grande.
De forma predeterminada, ESXi asigna memoria a páginas grandes. La división de páginas grandes en páginas pequeñas comienza cuando se alcanza el umbral de estado Alto y se fuerza cuando se alcanza el estado Borrar (consulte la tabla de estado del hipervisor).
Si desea que TPS comience a funcionar sin esperar a que se llene la RAM del host, en Opciones avanzadas ESXi debe establecer el valor “Mem.AllocGuestLargePage” a 0 (predeterminado 1). Luego, se deshabilitará la asignación de páginas de memoria grandes para máquinas virtuales.
Desde diciembre de 2014, en todas las versiones de ESXi, el TPS entre VM se ha desactivado de forma predeterminada, ya que se encontró una vulnerabilidad que teóricamente permite el acceso de una VM a la RAM de otra VM. Detalles aquí. No he encontrado información sobre la implementación práctica de la explotación de la vulnerabilidad TPS.
Política TPS controlada a través de la opción avanzada “Mem.ShareForceSalting” en ESXi:
0 - TPS entre máquinas virtuales. TPS funciona para páginas de diferentes máquinas virtuales;
1 – TPS para VM con el mismo valor “sched.mem.pshare.salt” en VMX;
2 (predeterminado): TPS intra-VM. TPS funciona para páginas dentro de la máquina virtual.
Definitivamente tiene sentido desactivar las páginas grandes y activar Inter-VM TPS en los bancos de pruebas. También se puede utilizar para soportes con una gran cantidad de máquinas virtuales del mismo tipo. Por ejemplo, en soportes con VDI, los ahorros en memoria física pueden alcanzar decenas de por ciento.
globo de memoria. El globo ya no es una técnica tan inofensiva y transparente para el sistema operativo de VM como TPS. Pero con la aplicación adecuada, puedes vivir e incluso trabajar con Globos Aerostáticos.
Junto con Vmware Tools, se instala en la VM un controlador especial llamado Balloon Driver (también conocido como vmmemctl). Cuando el hipervisor comienza a quedarse sin memoria física y entra en el estado blando, ESXi le pide a la máquina virtual que recupere la memoria RAM no utilizada a través de este controlador de globos. El controlador, a su vez, funciona a nivel del sistema operativo y le solicita memoria libre. El hipervisor ve qué páginas de memoria física ha ocupado el controlador de globo, toma la memoria de la máquina virtual y la devuelve al host. No hay problemas con el funcionamiento del SO, ya que a nivel de SO la memoria está ocupada por el Balloon Driver. De forma predeterminada, Balloon Driver puede ocupar hasta el 65 % de la memoria de la máquina virtual.
Si VMware Tools no está instalado en la máquina virtual o el globo está deshabilitado (no lo recomiendo, pero hay :), el hipervisor cambia inmediatamente a técnicas de eliminación de memoria más estrictas. Conclusión: asegúrese de que VMware Tools esté en la máquina virtual.
El funcionamiento de Balloon Driver se puede verificar desde el sistema operativo a través de VMware Tools.
compresión de memoria Esta técnica se usa cuando ESXi alcanza el estado Difícil. Como su nombre lo indica, ESXi intenta reducir una página de 4 KB de RAM a 2 KB y así liberar algo de espacio en la memoria física del servidor. Esta técnica aumenta significativamente el tiempo de acceso a los contenidos de las páginas RAM de la VM, ya que primero se debe descomprimir la página. A veces, no todas las páginas se pueden comprimir y el proceso en sí lleva algún tiempo. Por lo tanto, esta técnica no es muy efectiva en la práctica.
intercambio de memoria Después de una breve fase de compresión de memoria, ESXi casi inevitablemente (si las VM no se han ido a otros hosts o no se han apagado) cambiará a Intercambio. Y si queda muy poca memoria (estado bajo), el hipervisor también deja de asignar páginas de memoria a la máquina virtual, lo que puede causar problemas en el sistema operativo invitado de la máquina virtual.
Así es como funciona el intercambio. Cuando enciende una máquina virtual, se crea un archivo con la extensión .vswp para ella. Tiene el mismo tamaño que la RAM no reservada de la VM: es la diferencia entre la memoria configurada y la reservada. Cuando se ejecuta el intercambio, ESXi descarga las páginas de memoria de la máquina virtual en este archivo y comienza a trabajar con él en lugar de la memoria física del servidor. Por supuesto, dicha memoria "operativa" es varios órdenes de magnitud más lenta que la real, incluso si .vswp se encuentra en un almacenamiento rápido.
A diferencia de Ballooning, cuando las páginas no utilizadas se toman de la VM, con Swapping, las páginas que el sistema operativo o las aplicaciones dentro de la VM utilizan activamente pueden moverse al disco. Como resultado, el rendimiento de la máquina virtual cae hasta el punto de congelarse. La máquina virtual funciona formalmente y al menos se puede deshabilitar correctamente desde el sistema operativo. Si eres paciente 😉
Si las VM fueron a Swap, esta es una situación anormal, que es mejor evitar si es posible.
Contadores clave de rendimiento de memoria de VM
Así que llegamos al punto principal. Para monitorear el estado de la memoria en la VM, existen los siguientes contadores:
Active : muestra la cantidad de RAM (KB) a la que tuvo acceso la máquina virtual en el período de medición anterior.
Uso - lo mismo que Activo, pero como un porcentaje de la RAM configurada de la VM. Se calcula con la siguiente fórmula: activo ÷ tamaño de memoria configurado de la máquina virtual.
Alto uso y activo, respectivamente, no siempre son un indicador de problemas de rendimiento de la máquina virtual. Si la VM usa la memoria de forma agresiva (al menos tiene acceso a ella), esto no significa que no haya suficiente memoria. Más bien, es una ocasión para ver qué está pasando en el sistema operativo.
Hay una alarma de uso de memoria estándar para máquinas virtuales:
Compartido - la cantidad de RAM de VM deduplicada mediante TPS (dentro de la VM o entre VM).
Concedido - la cantidad de memoria de host física (KB) que se le dio a la máquina virtual. Incluye Compartido.
Consumado (Otorgado - Compartido): la cantidad de memoria física (KB) que la máquina virtual consume del host. No incluye Compartido.
Si parte de la memoria de la máquina virtual no proviene de la memoria física del host, sino del archivo de intercambio, o si la memoria se toma de la máquina virtual a través del controlador de globo, esta cantidad no se tiene en cuenta en Concedido y consumido.
Los valores altos concedidos y consumidos son perfectamente normales. El sistema operativo gradualmente toma memoria del hipervisor y no la devuelve. Con el tiempo, en una VM en ejecución activa, los valores de estos contadores se acercan a la cantidad de memoria configurada y permanecen ahí.
Cero — la cantidad de VM RAM (KB), que contiene ceros. El hipervisor considera que dicha memoria está libre y puede cederse a otras máquinas virtuales. Después de que el sistema operativo invitado haya escrito algo en la memoria puesta a cero, entra en Consumido y no regresa.
Gastos generales reservados — la cantidad de RAM de la VM, (KB) reservada por el hipervisor para el funcionamiento de la VM. Esta es una cantidad pequeña, pero debe estar disponible en el host; de lo contrario, la máquina virtual no se iniciará.
Globo — la cantidad de RAM (KB) incautada de la máquina virtual mediante el controlador de globo.
Comprimido - la cantidad de RAM (KB) que se comprimió.
Swapped - la cantidad de RAM (KB) que, debido a la falta de memoria física en el servidor, se movió al disco.
Los contadores de globo y otras técnicas de recuperación de memoria son cero.
Así es como se ve el gráfico con los contadores de memoria para una máquina virtual que funciona normalmente con 150 GB de RAM.
En el siguiente gráfico, la VM tiene problemas obvios. Debajo del gráfico, puede ver que para esta máquina virtual se usaron todas las técnicas descritas para trabajar con RAM. El globo para esta VM es mucho más grande que Consumido. De hecho, la máquina virtual está más muerta que viva.
ESXTOP
Al igual que con la CPU, si queremos evaluar rápidamente la situación en el host, así como su dinámica con un intervalo de hasta 2 segundos, debemos usar ESXTOP.
La pantalla ESXTOP por Memory se llama con la tecla "m" y se ve así (se seleccionan los campos B, D, H, J, K, L, O):
Los siguientes parámetros serán de nuestro interés:
Promedio de sobrecompromiso de memoria - el valor promedio de sobresuscripción de memoria en el host durante 1, 5 y 15 minutos. Si está por encima de cero, entonces esta es una ocasión para ver qué está pasando, pero no siempre es un indicador de problemas.
En lineas PMEM/MB и VMKMEM/MB - información sobre la memoria física del servidor y la memoria disponible para VMkernel. De lo interesante aquí puede ver el valor de minfree (en MB), el estado del host en la memoria (en nuestro caso, alto).
En línea NÚMERO/MB puede ver la distribución de RAM por nodos NUMA (sockets). En este ejemplo, la distribución es desigual, lo que, en principio, no es muy bueno.
Las siguientes son estadísticas generales del servidor sobre técnicas de recuperación de memoria:
COMPARTIR/MB son estadísticas TPS;
INTERCAMBIAR/MB — Estadísticas de uso de swaps;
C.P./MB — estadísticas de compresión de páginas de memoria;
MEMCTL/MB — Estadísticas de uso del controlador de globos.
Para máquinas virtuales individuales, es posible que nos interese la siguiente información. Oculté los nombres de las máquinas virtuales para no confundir a la audiencia :). Si la métrica de ESXTOP es similar al contador en vSphere, doy el contador correspondiente.
MEMSZ — la cantidad de memoria configurada en la VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + intacto.
GRANT — Otorgado a MB.
TCHD — Activo en MB.
¿MCTL? - si Balloon Driver está instalado en la máquina virtual.
MCTLSZ — Globo a MB.
MCTLGT — la cantidad de RAM (MB) que ESXi quiere tomar de la VM a través de Balloon Driver (Memctl Target).
MCTLMAX - la cantidad máxima de RAM (MB) que ESXi puede tomar de la máquina virtual a través del controlador de globos.
SWCUR — la cantidad actual de RAM (MB) asignada a la máquina virtual desde el archivo de intercambio.
SWGT. - la cantidad de RAM (MB) que ESXi quiere dar a la VM desde el archivo de intercambio (Swap Target).
Además, a través de ESXTOP, puede ver información más detallada sobre la topología NUMA de la VM. Para ello, seleccione los campos D, G:
PEQUEÑA – Nodos NUMA en los que se encuentra la VM. Aquí puede notar inmediatamente vm anchos, que no caben en un nodo NUMA.
NRMEM - cuántos megabytes de memoria toma la máquina virtual del nodo NUMA remoto.
NLMEM - cuántos megabytes de memoria toma la máquina virtual del nodo NUMA local.
N%L – porcentaje de memoria de VM en el nodo NUMA local (si es inferior al 80 %, pueden producirse problemas de rendimiento).
Memoria en el hipervisor
Si los contadores de CPU para el hipervisor no suelen ser de particular interés, entonces la situación se invierte con la memoria. El uso elevado de memoria en una máquina virtual no siempre indica un problema de rendimiento, pero el uso elevado de memoria en un hipervisor desencadena técnicas de administración de memoria y provoca problemas de rendimiento en la máquina virtual. Las alarmas de uso de la memoria del host deben monitorearse para evitar que la máquina virtual entre en intercambio.
desintercambiar
Si una máquina virtual está en intercambio, su rendimiento se reduce considerablemente. Los rastros de globo y compresión desaparecen rápidamente después de que aparece RAM libre en el host, pero la máquina virtual no tiene prisa por regresar de Swap a la RAM del servidor.
Antes de ESXi 6.0, la única forma confiable y rápida de sacar una máquina virtual de Swap era reiniciar (para ser más precisos, apagar/encender el contenedor). A partir de ESXi 6.0, aunque no es del todo oficial, ha aparecido una forma confiable y funcional de eliminar una VM de Swap. En una de las conferencias, pude hablar con uno de los ingenieros de VMware a cargo de CPU Scheduler. Confirmó que el método funciona bastante bien y es seguro. En nuestra experiencia, tampoco hubo problemas con eso.
Los comandos reales para eliminar la máquina virtual del intercambio Duncan Epping. No repetiré una descripción detallada, solo daré un ejemplo de su uso. Como puede ver en la captura de pantalla, algún tiempo después de la ejecución de los comandos especificados, Swap desaparece en la VM.
Sugerencias de administración de memoria ESXi
Finalmente, aquí hay algunos consejos que lo ayudarán a evitar problemas con el rendimiento de la VM debido a la RAM:
- Evite la sobresuscripción de memoria en clústeres productivos. Es deseable tener siempre ~20-30 % de memoria libre en el clúster para que DRS (y el administrador) tengan espacio para maniobrar y las máquinas virtuales no entren en intercambio durante la migración. Además, no se olvide del margen de tolerancia a fallos. Es desagradable cuando, cuando un servidor falla y la VM se reinicia usando HA, algunas de las máquinas también entran en Swap.
- En infraestructuras altamente consolidadas, intente NO crear máquinas virtuales con más de la mitad de la memoria del host. De nuevo, esto ayudará a DRS a distribuir las máquinas virtuales entre los servidores del clúster sin ningún problema. Esta regla, por supuesto, no es universal :).
- Esté atento a la alarma de uso de la memoria del host.
- No olvide instalar VMware Tools en la máquina virtual y no desactive Globos.
- Considere habilitar Inter-VM TPS y deshabilitar Páginas grandes en VDI y entornos de prueba.
- Si la máquina virtual tiene problemas de rendimiento, verifique si está usando la memoria de un nodo NUMA remoto.
- ¡Saca tu VM de Swap lo más rápido posible! Entre otras cosas, si la VM está en Swap, por razones obvias, el sistema de almacenamiento se resiente.
Eso es todo para mí sobre la memoria RAM. A continuación hay un artículo relacionado para aquellos que quieran profundizar en los detalles. El próximo artículo estará dedicado a storadzh.
Enlaces de interés
Fuente: habr.com