Aquí hay mucho más que solo ESXi en cuestión,
- Cada VM consumirá hasta 4 GB + "gastos generales", que se documenta aquí . Esto depende de las vCPU, + memoria asignada. Como mínimo, cada VM usará 4261.98 MB (4096 + 165.98)
- Sobrecarga de memoria propia de ESXi, esto depende del hardware. La opción más fácil es mirar el uso de memoria del sistema en el cliente vSphere. De memoria, recuerdo que está alrededor de la marca de 1.3 GB, pero como se dijo, depende mucho del hardware.
Asignación de memoria y sobrecompromiso explicado
Tenga en cuenta que el hipervisor no asignará toda esa memoria por adelantado , depende del uso de la VM. Sin embargo, vale la pena entender lo que sucederá si las máquinas virtuales intentan asignar y utilizar toda la memoria asignada a ellas.
El máximo que su host VM + intentará usar será aproximadamente, 55 GB de kilometraje pueden variar
- 1.3 GB utilizados por ESXi
- 4261,98 MB * 13 utilizados por las máquinas virtuales
Hay otro aspecto a tener en cuenta y son los umbrales de memoria. De forma predeterminada, VMware tendrá como objetivo tener un 6% libre (umbral de memoria alto). Por lo tanto, los 55 GB de memoria utilizada deben reducirse a ~ 45 GB
Eso significa que el host tendrá aproximadamente 10,500 MB de memoria que necesita recuperar de alguna parte si las máquinas virtuales usan la memoria que se les ha asignado. Hay tres cosas que ESX hace para encontrar esos 10.5 GB adicionales.
Métodos de recuperación de memoria
- Uso compartido de páginas transparente
- Globos de memoria
- Intercambio de hipervisor
Debe leer y comprender la gestión de recursos de memoria en VMware® ESX ™ Server .
Dependiendo de una gran cantidad de factores, una combinación de los tres sucederá / podría suceder en un host demasiado comprometido. Debe probar su entorno y monitorear estas métricas para comprender el impacto de un compromiso excesivo.
Algunas reglas aproximadas que vale la pena conocer (todas en el documento anterior y otras fuentes).
- El uso compartido de páginas transparente no ocurre para máquinas virtuales que usan páginas de 2/4 MB. Como ha asignado 4096 MB a sus máquinas virtuales de Windows, utilizarán las páginas de 2/4 MB de forma predeterminada (depende de PAE). Solo bajo presión de memoria VMware dividirá las páginas grandes en páginas de 4 KB que se pueden compartir. TPS se basa en el uso de ciclos de CPU inactivos y el escaneo de páginas de memoria a una velocidad determinada. Devuelve la memoria con relativa lentitud (piense una hora en lugar de minutos). Entonces, una tormenta de arranque significará que TPS no lo ayudará. De los tres, esto tiene el menor impacto en el rendimiento. Más del documento,
En los sistemas de virtualización de memoria asistida por hardware (por ejemplo, Intel EPT Hardware Assist y AMD RVI Hardware Assist [6]), ESX respaldará automáticamente las páginas físicas invitadas con páginas físicas de host grandes (región de memoria contigua de 2 MB en lugar de 4KB para páginas normales) para mejor rendimiento debido a menos fallas de TLB. En tales sistemas, ESX no compartirá esas páginas grandes porque: 1) la probabilidad de encontrar dos páginas grandes con contenido idéntico es baja, y 2) la sobrecarga de hacer una comparación bit por bit para una página de 2MB es mucho mayor que para una página de 4KB. Sin embargo, ESX todavía genera hashes para las páginas de 4KB dentro de cada página grande. Dado que ESX no intercambiará páginas grandes, durante el intercambio de host, la página grande se dividirá en páginas pequeñas para que estos hash pregenerados se puedan usar para compartir las páginas pequeñas antes de que se intercambien. En resumen, es posible que no observemos ningún intercambio de páginas para sistemas de virtualización de memoria asistida por hardware hasta que la memoria del host se haya comprometido en exceso.
El globo comienza después (los umbrales son configurables, por defecto esto es cuando el host tiene menos del 6% de memoria libre (entre alta y software)). Asegúrese de instalar el controlador y tenga cuidado con Java y las aplicaciones administradas en general. El sistema operativo no tiene una idea de lo que hará el recolector de basura a continuación y terminará golpeando páginas que se han cambiado al disco. No es una práctica poco común que los servidores que ejecutan aplicaciones java exclusivamente deshabiliten el intercambio por completo para garantizar que eso no suceda. Eche un vistazo a la página 17 de vSphere Memory Management, SPECjbb
El intercambio de hipervisor , de los tres métodos, es el único que garantiza que la "memoria" esté disponible para el hipervisor en un tiempo establecido. Esto se usará si 1 y 2 no le dan suficiente memoria para permanecer por debajo del umbral rígido (valor predeterminado del 2% de memoria libre). Cuando lea las métricas de rendimiento (haga las suyas propias), se dará cuenta de que este es el peor desempeño de los tres. Intente evitarlo a toda costa, ya que el impacto en el rendimiento será muy notable en casi todas las aplicaciones, porcentaje de dos dígitos
Hay un estado más para tener en cuenta bajo (por defecto 1%). Desde el manual, esto puede reducir drásticamente su rendimiento,
En un caso raro en el que la memoria libre del host cae por debajo del umbral bajo, el hipervisor continúa recuperando la memoria mediante el intercambio y la compresión de la memoria, y además bloquea la ejecución de todas las máquinas virtuales que consumen más memoria que sus asignaciones de memoria de destino.
Resumen
El punto clave a destacar es que es imposible predecir a partir de los documentos técnicos cómo se comportará su entorno.
- ¿Cuánto te puede dar TPS? (Depende de cuán similares sean sus máquinas virtuales con su sistema operativo, Service Pack y aplicaciones en ejecución)
- ¿Con qué rapidez asignan sus máquinas virtuales su memoria? Cuanto más rápido lo hagan, es más probable que salte al siguiente umbral antes de que el esquema de recuperación de memoria menos impactante logre mantenerlo en su umbral actual.
- Dependiendo de la aplicación, cada esquema de recuperación de memoria tendrá un impacto muy variable.
Pon a prueba tus escenarios promedio, eres un escenario de percentil del 95% y finalmente tu máximo para comprender cómo funcionará tu entorno.
Editar 1
Vale la pena agregar que con vSphere 4 (o 4.1 no se puede recordar), ahora es posible colocar el intercambio del hipervisor en el disco local pero aún así vmotion la VM. Si está utilizando almacenamiento compartido, le recomiendo que mueva el archivo de intercambio del hipervisor para que esté en el disco local de forma predeterminada. Esto garantiza que cuando un host está bajo una presión de memoria severa, no termina afectando a todos los demás hosts / VM vSphere en el mismo almacenamiento compartido.
Editar 2
Según los comentarios, hizo que ESX no asigne la memoria por adelantado en negrita ...
Editar 3
Explicó un poco más sobre los umbrales de memoria.