{"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\/es\/blog\/administrirovanie\/analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory","title":{"rendered":"An\u00e1lisis del rendimiento de las VM en VMware vSphere. Parte 2: Memoria","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"An\u00e1lisis
\n
\nParte 1. Sobre la CPU<\/a><\/noindex><\/p>\n

En este art\u00edculo hablaremos sobre los contadores de rendimiento de la memoria RAM en vSphere.
\nParece que con la memoria es todo m\u00e1s claro que con el procesador: si hay problemas de rendimiento en una VM, es dif\u00edcil no notarlos. Pero cuando aparecen, es mucho m\u00e1s complicado solucionarlos. Pero vayamos por partes. <\/a><\/noindex><\/p>\n

Un poco de teor\u00eda<\/h3>\n

\nLa memoria RAM de las m\u00e1quinas virtuales proviene de la memoria del servidor en el que operan las VMs. Esto es bastante obvio :). Si el servidor no tiene suficiente memoria RAM para todos los que la necesitan, ESXi comienza a aplicar t\u00e9cnicas de optimizaci\u00f3n del uso de la memoria (t\u00e9cnicas de recuperaci\u00f3n de memoria). De lo contrario, los sistemas operativos de las VMs fallar\u00edan debido a errores de acceso a la RAM. <\/p>\n

Qu\u00e9 t\u00e9cnicas aplica ESXi depende de la carga de la memoria RAM:<\/p>\n

Estado de la memoria<\/b><\/p>\n

L\u00edmite<\/b><\/p>\n

Acciones<\/b><\/p>\n

Alto<\/p>\n

400% de minFree<\/p>\n

Despu\u00e9s de alcanzar el l\u00edmite superior, las grandes p\u00e1ginas de memoria se dividen en peque\u00f1as (TPS funciona en modo est\u00e1ndar).<\/p>\n

Limpiar<\/p>\n

100% de minFree<\/p>\n

Las grandes p\u00e1ginas de memoria se dividen en peque\u00f1as, TPS funciona forzosamente.<\/p>\n

Soft<\/p>\n

64% de minFree<\/p>\n

TPS + Balloon<\/p>\n

Duro<\/p>\n

32% de minFree<\/p>\n

TPS + Comprimir + Intercambiar<\/p>\n

Bajo<\/p>\n

16% de minFree<\/p>\n

Comprimir + Intercambiar + Bloquear<\/p>\n

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

minFree es la memoria RAM necesaria para el funcionamiento del hipervisor. <\/p>\n

Hasta ESXi 4.1 inclusive, minFree por defecto era fijo: 6% de la capacidad de memoria RAM del servidor (el porcentaje se pod\u00eda cambiar a trav\u00e9s de la opci\u00f3n Mem.MinFreePct en ESXi). En versiones posteriores, debido al aumento en las capacidades de memoria en los servidores, minFree empez\u00f3 a calcularse en funci\u00f3n de la capacidad de memoria del host, en lugar de como un valor porcentual fijo. <\/p>\n

El valor de minFree (por defecto) se calcula de la siguiente manera:<\/p>\n

Porcentaje de memoria reservado para minFree<\/b><\/p>\n

Rango de memoria<\/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

Memoria restante<\/p>\n

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

Por ejemplo, para un servidor con 128 GB de RAM, el valor de MinFree ser\u00e1 el siguiente:
\nMinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
\nEl valor real puede diferir en un par de cientos de MB, esto depende del servidor y la memoria RAM.<\/p>\n

Porcentaje de memoria reservado para minFree<\/b><\/p>\n

Rango de memoria<\/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

Memoria restante (100 GB)<\/p>\n

1024 MB<\/p>\n

\nGeneralmente, para entornos de producci\u00f3n solo se considera normal el estado Alto. Para entornos de pruebas y desarrollo, los estados Limpiar\/Suave pueden ser aceptables. Si la memoria RAM en el host queda por debajo del 64% de MinFree, las VMs que operan en \u00e9l seguramente experimentar\u00e1n problemas de rendimiento.<\/p>\n

En cada estado se aplican ciertas t\u00e9cnicas de reclamaci\u00f3n de memoria, comenzando con TPS, que pr\u00e1cticamente no afecta el rendimiento de la VM, y terminando con swapping. Hablar\u00e9 de ellas con m\u00e1s detalle. <\/p>\n

Transparent Page Sharing (TPS).<\/b> TPS es, en t\u00e9rminos simples, deduplicaci\u00f3n de p\u00e1ginas de memoria RAM de m\u00e1quinas virtuales en el servidor.<\/p>\n

ESXi busca p\u00e1ginas de memoria RAM id\u00e9nticas de m\u00e1quinas virtuales, calculando y comparando el hash de las p\u00e1ginas, y elimina las duplicadas, reemplaz\u00e1ndolas por enlaces a la misma p\u00e1gina en la memoria f\u00edsica del servidor. Como resultado, el consumo de memoria f\u00edsica se reduce y se puede lograr cierta sobreasignaci\u00f3n de memoria pr\u00e1cticamente sin disminuir el rendimiento.<\/p>\n

\"An\u00e1lisis
\nFuente<\/a><\/noindex><\/p>\n

Este mecanismo solo funciona para p\u00e1ginas de memoria de 4 KB (p\u00e1ginas peque\u00f1as). El hipervisor ni siquiera intenta deduplicar p\u00e1ginas de 2 MB (p\u00e1ginas grandes): la probabilidad de encontrar p\u00e1ginas id\u00e9nticas de ese tama\u00f1o no es alta.<\/p>\n

Por defecto, ESXi asigna memoria a las p\u00e1ginas grandes. La fragmentaci\u00f3n de p\u00e1ginas grandes en peque\u00f1as comienza al alcanzar un umbral de estado Alto y ocurre de forma forzosa cuando se alcanza el estado Claro (ver tabla de estados del hipervisor).<\/p>\n

Si desea que TPS comience a funcionar sin esperar a llenar la memoria RAM del host, debe establecer el valor en las Opciones Avanzadas de ESXi \u201cMem.AllocGuestLargePage\u201d<\/i> en 0 (por defecto 1). Entonces, la asignaci\u00f3n de grandes p\u00e1ginas de memoria para m\u00e1quinas virtuales se desactivar\u00e1.<\/p>\n

Desde diciembre de 2014, en todos los lanzamientos de ESXi, TPS entre VMs est\u00e1 desactivado por defecto, ya que se encontr\u00f3 una vulnerabilidad que te\u00f3ricamente permite acceder a la memoria RAM de otra VM desde una. M\u00e1s detalles aqu\u00ed. No he encontrado informaci\u00f3n sobre la implementaci\u00f3n pr\u00e1ctica de la explotaci\u00f3n de la vulnerabilidad TPS.<\/p>\n

La pol\u00edtica TPS se controla a trav\u00e9s de la opci\u00f3n avanzada \u201cMem.ShareForceSalting\u201d<\/i> en ESXi:
\n0 \u2014 TPS inter-VM. TPS funciona para p\u00e1ginas de diferentes VMs;
\n1 \u2013 TPS para VMs con el mismo valor de \u201csched.mem.pshare.salt\u201d en VMX;
\n2 (por defecto) \u2013 TPS intra-VM. TPS funciona para p\u00e1ginas dentro de la VM.<\/p>\n

Sin duda, tiene sentido desactivar las p\u00e1ginas grandes e incluir TPS inter-VM en bancos de pruebas. Tambi\u00e9n se puede utilizar para entornos con un gran n\u00famero de VMs similares. Por ejemplo, en entornos con VDI, el ahorro de memoria f\u00edsica puede alcanzar d\u00e9cimas de porcentaje. <\/p>\n

Memory Ballooning.<\/b> El Ballooning ya no es tan inofensivo y transparente para el sistema operativo de las m\u00e1quinas virtuales como lo es TPS. Pero con un uso adecuado, se puede convivir e incluso trabajar con Ballooning.<\/p>\n

Junto con Vmware Tools, se instala un controlador especial en la m\u00e1quina virtual, llamado Balloon Driver (tambi\u00e9n conocido como vmmemctl). Cuando al hipervisor le falta memoria f\u00edsica y entra en estado Soft, ESXi solicita a la m\u00e1quina virtual que devuelva la memoria RAM no utilizada a trav\u00e9s de este Balloon Driver. A su vez, el controlador opera a nivel del sistema operativo y solicita memoria libre de este. El hipervisor ve qu\u00e9 p\u00e1ginas de memoria f\u00edsica ha ocupado el Balloon Driver, toma memoria de la m\u00e1quina virtual y la devuelve al host. No hay problemas en el funcionamiento del sistema operativo, ya que a nivel del sistema operativo la memoria est\u00e1 ocupada por el Balloon Driver. Por defecto, el Balloon Driver puede reclamar hasta el 65% de la memoria de la m\u00e1quina virtual.<\/p>\n

Si no est\u00e1n instalados VMware Tools en la m\u00e1quina virtual o si se desactiva el Ballooning (no lo recomiendo, pero existe KB<\/a><\/noindex>:), el hipervisor inmediatamente recurre a t\u00e9cnicas m\u00e1s dr\u00e1sticas para la reclamaci\u00f3n de memoria. Conclusi\u00f3n: aseg\u00farate de que VMware Tools est\u00e9n instalados en la m\u00e1quina virtual.<\/p>\n

\"An\u00e1lisis
\nSe puede verificar el funcionamiento del Balloon Driver desde el sistema operativo a trav\u00e9s de VMware Tools.<\/i>.<\/p>\n

Compresi\u00f3n de Memoria.<\/b> Esta t\u00e9cnica se aplica cuando ESXi alcanza el estado Hard. Como indica el nombre, ESXi intenta comprimir p\u00e1ginas de 4 Kbytes de memoria RAM a 2 Kbytes y as\u00ed liberar un poco de espacio en la memoria f\u00edsica del servidor. Esta t\u00e9cnica aumenta significativamente el tiempo de acceso al contenido de las p\u00e1ginas de memoria de la m\u00e1quina virtual, ya que la p\u00e1gina debe descomprimirse previamente. A veces, no todas las p\u00e1ginas se pueden comprimir, y el propio proceso lleva cierto tiempo. Por lo tanto, en la pr\u00e1ctica, esta t\u00e9cnica no es muy efectiva.<\/p>\n

Intercambio de Memoria.<\/b> Despu\u00e9s de una breve fase de Compresi\u00f3n de Memoria, ESXi pr\u00e1cticamente inevitablemente (si las m\u00e1quinas virtuales no se han trasladado a otros hosts o no se han apagado) pasa al intercambio. Y si queda muy poca memoria (estado Bajo), el hipervisor tambi\u00e9n deja de asignar p\u00e1ginas de memoria a la m\u00e1quina virtual, lo que puede causar problemas en los sistemas operativos invitados de la m\u00e1quina virtual.<\/p>\n

As\u00ed es como funciona el Swapping. Al encender la m\u00e1quina virtual, se crea un archivo con la extensi\u00f3n .vswp. Su tama\u00f1o es igual a la memoria RAM no reservada de la VM: esta es la diferencia entre la memoria configurada y la reservada. Durante el proceso de Swapping, ESXi descarga las p\u00e1ginas de memoria de la m\u00e1quina virtual a este archivo y comienza a trabajar con \u00e9l en lugar de con la memoria f\u00edsica del servidor. Por supuesto, esta \"memoria RAM\" es varios \u00f3rdenes de magnitud m\u00e1s lenta que la real, incluso si .vswp est\u00e1 en un almacenamiento r\u00e1pido.<\/p>\n

A diferencia del Ballooning, cuando se quitan p\u00e1ginas no utilizadas de la VM, en el Swapping pueden trasladarse al disco p\u00e1ginas que est\u00e1n siendo utilizadas activamente por el sistema operativo o aplicaciones dentro de la VM. Como resultado, el rendimiento de la VM disminuye incluso hasta colapsar. La VM sigue funcionando formalmente y al menos se puede apagar correctamente desde el sistema operativo. Si tienes paciencia \ud83d\ude09<\/p>\n

Si la VM ha sido desplazada a Swap, esta es una situaci\u00f3n an\u00f3mala que es mejor evitar si es posible.<\/p>\n

Principales contadores de rendimiento de la memoria de la m\u00e1quina virtual<\/h3>\n

\nAqu\u00ed llegamos a lo importante. Para monitorear el estado de la memoria en la VM, existen los siguientes contadores:<\/p>\n

Activo<\/b> \u2014 muestra la cantidad de memoria RAM (KB) a la que la VM tuvo acceso en el per\u00edodo de medici\u00f3n anterior.<\/p>\n

Uso<\/b> \u2014 lo mismo que Activo, pero en porcentaje de la memoria RAM configurada de la VM. Se calcula con la siguiente f\u00f3rmula: activo \u00f7 tama\u00f1o de memoria configurada de la m\u00e1quina virtual.
\nUn alto Uso y Activo, respectivamente, no siempre son indicadores de problemas de rendimiento en la VM. Si la VM est\u00e1 utilizando la memoria de manera agresiva (como m\u00ednimo, accediendo a ella), no significa que falte memoria. M\u00e1s bien, es motivo para investigar qu\u00e9 est\u00e1 ocurriendo en el sistema operativo.
\nHay una alarma est\u00e1ndar por Uso de Memoria para la VM:<\/p>\n

\"An\u00e1lisis
\n
\nCompartido<\/b> \u2014 cantidad de memoria RAM de la VM, deduplicada mediante TPS (dentro de la VM o entre VMs).<\/p>\n

Concedido<\/b> \u2014 cantidad de memoria f\u00edsica del host (KB) que se ha asignado a la VM. Incluye Compartida.<\/p>\n

Consumido<\/b> (Concedido \u2014 Compartido) \u2014 cantidad de memoria f\u00edsica (KB) que la VM consume del host. No incluye Compartida.<\/p>\n

Si parte de la memoria de la VM se asigna no desde la memoria f\u00edsica del host, sino desde un archivo de intercambio o se retira de la VM mediante el Driver de Balloon, esta cantidad no se tiene en cuenta en Concedido y Consumido.
\nLos altos valores de Granted y Consumed son totalmente normales. El sistema operativo gradualmente retira memoria del hipervisor y no la devuelve. Con el tiempo, en una VM activamente operativa, los valores de estos contadores se acercan al volumen de memoria configurada y permanecen all\u00ed.<\/p>\n

Cero<\/b> \u2014 el volumen de memoria RAM de la VM (Kbytes) que contiene ceros. Esta memoria es considerada libre por el hipervisor y puede ser asignada a otras m\u00e1quinas virtuales. Despu\u00e9s de que el sistema operativo invitado haya escrito algo en la memoria nulificada, esta se convierte en Consumed y ya no se devuelve.<\/p>\n

Reserved Overhead<\/b> \u2014 el volumen de memoria RAM de la VM (Kbytes) reservado por el hipervisor para la operaci\u00f3n de la VM. Es un volumen peque\u00f1o, pero debe estar disponible en el host; de lo contrario, la VM no se iniciar\u00e1.<\/p>\n

Balloon<\/b> \u2014 el volumen de memoria RAM (Kbytes) extra\u00eddo de la VM mediante el Balloon Driver.<\/p>\n

Compressed<\/b> \u2014 el volumen de memoria RAM (Kbytes) que se ha logrado comprimir.<\/p>\n

Swapped<\/b> \u2014 el volumen de memoria RAM (Kbytes) que, por falta de memoria f\u00edsica en el servidor, ha sido trasladado al disco.
\nBalloon y otros contadores de t\u00e9cnicas de recuperaci\u00f3n de memoria son iguales a cero.<\/p>\n

As\u00ed es como se ve el gr\u00e1fico con los contadores de una VM funcionando correctamente con 150 GB de RAM.<\/p>\n

\"An\u00e1lisis
\n
\nEn el gr\u00e1fico a continuaci\u00f3n, la VM presenta claros problemas. Debajo del gr\u00e1fico se puede ver que para esta VM se han utilizado todas las t\u00e9cnicas descritas para la gesti\u00f3n de la memoria. Balloon es significativamente mayor que Consumed para esta VM. De hecho, la VM est\u00e1 m\u00e1s muerta que viva. <\/p>\n

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

ESXTOP<\/h3>\n

\nAl igual que con la CPU, si queremos evaluar r\u00e1pidamente la situaci\u00f3n en el host, as\u00ed como su din\u00e1mica en intervalos de hasta 2 segundos, se recomienda utilizar ESXTOP.<\/p>\n

La pantalla de ESXTOP para la memoria se activa con la tecla \"m\" y se ve de la siguiente manera (se seleccionaron los campos B,D,H,J,K,L,O):<\/p>\n

\"An\u00e1lisis
\n
\nLos siguientes par\u00e1metros ser\u00e1n interesantes para nosotros: <\/p>\n

Mem overcommit avg<\/b> \u2014 el valor promedio de sobreasignaci\u00f3n de memoria en el host durante 1, 5 y 15 minutos. Si est\u00e1 por encima de cero, es un motivo para examinar qu\u00e9 est\u00e1 sucediendo, aunque no siempre indica la presencia de problemas.<\/p>\n

En las l\u00edneas PMEM\/MB<\/b> y VMKMEM\/MB<\/b> \u2014 informaci\u00f3n sobre la memoria f\u00edsica del servidor y la memoria disponible para VMkernel. Aqu\u00ed se puede ver el valor minfree (en MB), el estado de la memoria del host (en nuestro caso, alto).<\/p>\n

En la l\u00ednea NUMA\/MB<\/b> se puede ver la distribuci\u00f3n de la memoria RAM entre los nodos NUMA (z\u00f3calos). En este ejemplo, la distribuci\u00f3n es desigual, lo cual no es muy bueno en general.<\/p>\n

A continuaci\u00f3n se presenta la estad\u00edstica general del servidor sobre las t\u00e9cnicas de recuperaci\u00f3n de memoria:<\/p>\n

PSHARE\/MB<\/b> \u2014 es la estad\u00edstica de TPS;<\/p>\n

SWAP\/MB<\/b> \u2014 estad\u00edstica del uso de Swap;<\/p>\n

ZIP\/MB<\/b> \u2014 estad\u00edstica de compresi\u00f3n de p\u00e1ginas de memoria;<\/p>\n

MEMCTL\/MB<\/b> \u2014 estad\u00edstica del uso del Balloon Driver.<\/p>\n

Para cada VM, puede interesarnos la siguiente informaci\u00f3n. He ocultado los nombres de las VMs para no confundir a la audiencia:). Si la m\u00e9trica ESXTOP es an\u00e1loga al contador en vSphere, indico el contador correspondiente. <\/p>\n

MEMSZ<\/b> \u2014 el volumen de memoria configurado en la VM (MB).
\nMEMSZ = GRANT + MCTLSZ + SWCUR + untouched.<\/p>\n

GRANT<\/b> \u2014 Granted en megabytes.<\/p>\n

TCHD<\/b> \u2014 Activo en megabytes.<\/p>\n

MCTL?<\/b> \u2014 si est\u00e1 instalado el Balloon Driver en la VM.<\/p>\n

MCTLSZ<\/b> \u2014 Balloon en megabytes.<\/p>\n

MCTLGT<\/b> \u2014 cantidad de RAM (megabytes) que ESXi desea recuperar de la VM a trav\u00e9s del Balloon Driver (Memctl Target).<\/p>\n

MCTLMAX<\/b> \u2014 cantidad m\u00e1xima de RAM (megabytes) que ESXi puede recuperar de la VM a trav\u00e9s del Balloon Driver.<\/p>\n

SWCUR<\/b> \u2014 cantidad actual de RAM (megabytes) asignada a la VM desde el archivo de Swap. <\/p>\n

SWGT<\/b> \u2014 cantidad de RAM (megabytes) que ESXi desea asignar a la VM desde el archivo de Swap (Swap Target).<\/p>\n

Tambi\u00e9n a trav\u00e9s de ESXTOP se puede ver informaci\u00f3n m\u00e1s detallada sobre la topolog\u00eda NUMA de la VM. Para esto, se deben seleccionar los campos D,G:<\/p>\n

\"An\u00e1lisis
\n
\nNHN<\/b> \u2013 nodos NUMA donde se encuentra la VM. Aqu\u00ed se pueden notar inmediatamente VMs amplias que no caben en un solo nodo NUMA.<\/p>\n

NRMEM<\/b> \u2013 cu\u00e1ntos megabytes de memoria toma la VM de un nodo NUMA remoto.<\/p>\n

NLMEM<\/b> \u2013 cu\u00e1ntos megabytes de memoria toma la VM de un nodo NUMA local.<\/p>\n

N%L<\/b> \u2013 porcentaje de memoria de la VM en el nodo NUMA local (si es menos del 80% \u2014 pueden surgir problemas de rendimiento).<\/p>\n

Memoria en el hipervisor<\/h3>\n

\nSi los contadores de CPU en el hipervisor generalmente no representan un gran inter\u00e9s, la situaci\u00f3n con la memoria es diferente. Un alto uso de memoria en la VM no siempre indica un problema de rendimiento, pero un alto uso de memoria en el hipervisor s\u00ed activa t\u00e9cnicas de gesti\u00f3n de memoria y provoca problemas de rendimiento en la VM. Debemos estar atentos a las alarmas de uso de memoria del host y evitar que las VMs caigan en Swap.<\/p>\n

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

Unswap<\/h3>\n

\nSi la VM ha ca\u00eddo en Swap, su rendimiento disminuye dr\u00e1sticamente. Las huellas del Ballooning y la compresi\u00f3n desaparecen r\u00e1pidamente despu\u00e9s de que hay memoria RAM libre en el host, pero la m\u00e1quina virtual no se apresura a volver de Swap a la RAM del servidor.
\nHasta la versi\u00f3n ESXi 6.0, la \u00fanica forma confiable y r\u00e1pida de sacar una VM del Swap era reiniciar (m\u00e1s precisamente, apagar\/encender el contenedor). A partir de ESXi 6.0, surgi\u00f3 un m\u00e9todo que, aunque no es del todo oficial, es funcional y confiable para sacar una VM del Swap. En una de las conferencias, tuve la oportunidad de hablar con uno de los ingenieros de VMware a cargo del programador de CPU. Confirm\u00f3 que este m\u00e9todo es completamente seguro y operativo. En nuestra experiencia, no hemos tenido problemas con \u00e9l.<\/p>\n

Comandos para sacar VMs del Swap describi\u00f3<\/a><\/noindex> Duncan Epping. No repetir\u00e9 la descripci\u00f3n completa, solo ofrecer\u00e9 un ejemplo de su uso. Como se puede ver en la captura de pantalla, despu\u00e9s de un tiempo tras ejecutar el comando, el Swap en la VM desaparece.<\/p>\n

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

Consejos para la gesti\u00f3n de memoria en ESXi<\/h3>\n

\nPor \u00faltimo, aqu\u00ed hay algunos consejos que te ayudar\u00e1n a evitar problemas de rendimiento en las VMs debido a la memoria:<\/p>\n