¿Cuánta contención es demasiado en VMware?

Durante un tiempo, he estado tratando de entender por qué algunos de nuestros sistemas críticos para el negocio están recibiendo informes de "lentitud" que van de leves a extremos. Recientemente he dirigido mi atención al entorno VMware donde están alojados todos los servidores en cuestión.

Recientemente descargué e instalé la versión de prueba del paquete de administración Veeam VMware para SCOM 2012, pero me cuesta creer (y también mi jefe) los números que me informa. Para tratar de convencer a mi jefe de que los números que me dice son ciertos, comencé a buscar en el cliente VMware para verificar los resultados.

He mirado este artículo de VMware KB ; específicamente para la definición de Co-Stop que se define como:

Cantidad de tiempo que una máquina virtual MP estaba lista para ejecutarse, pero sufrió un retraso debido a la contención de programación de co-vCPU

A lo que estoy traduciendo

El sistema operativo invitado necesita tiempo del host, pero tiene que esperar a que los recursos estén disponibles y, por lo tanto, puede considerarse "que no responde"

¿Esta traducción parece correcta?

Si es así, aquí es donde me cuesta creer lo que estoy viendo: ¡el host que contiene la mayoría de las máquinas virtuales que son "lentas" muestra actualmente un promedio de CPU Co-stop promedio de 127,835.94 milisegundos!

¿Significa esto que, en promedio, las máquinas virtuales en este host tienen que esperar más de 2 minutos para el tiempo de CPU?

Este host tiene dos CPU de 4 núcleos y tiene un invitado de CPU 1x8 y invitados de CPU 14x4.

Puedo describir algunas de las experiencias que he tenido en esta área ...

No creo que VMware haga un trabajo adecuado al educar a los clientes ( o administradores ) sobre las mejores prácticas, ni actualizan las mejores prácticas anteriores a medida que sus productos evolucionan. Esta pregunta es un ejemplo de cómo un concepto central como la asignación de vCPU no se entiende completamente. El mejor enfoque es comenzar en pequeño, con una sola vCPU, hasta que determine que la VM requiere más.

Para el OP, el servidor host ESXi tiene dos CPU de cuatro núcleos, que producen 8 núcleos físicos.

El diseño de la máquina virtual que se describe es de 15 invitados en total; Sistemas de 1 x 8 vCPU y 14 x 4 vCPU. Eso es demasiado comprometido, especialmente con la existencia de un solo invitado con 8 vCPU . No tiene sentido. Si necesita una VM tan grande, es probable que necesite un servidor más grande.

Intente dimensionar correctamente sus máquinas virtuales. Estoy bastante seguro de que la mayoría de ellos pueden vivir con 2 vCPU. Agregar CPU virtuales no hace que las cosas funcionen más rápido, por lo que si eso es un remedio para un problema de rendimiento, es el enfoque equivocado.

En la mayoría de los entornos, la RAM es el recurso más limitado. Pero la CPU puede ser un problema si hay demasiada contención. Tienes evidencia de esto. La RAM también puede ser un problema si se asigna demasiado a máquinas virtuales individuales .

Es posible monitorear esto. La métrica que está buscando es "CPU Ready%". Puede acceder a este desde el cliente vSphere mediante la selección de una máquina virtual e ir a Performance> Overview> CPU Gráfico.

• Menos del 5% de CPU lista : estás bien.
• 5-10% CPU Ready : observe de cerca la actividad.
• Más del 10% de CPU lista : no es bueno.

Tenga en cuenta la línea amarilla en el gráfico a continuación.

¿Le importaría verificar esto en sus máquinas virtuales problemáticas e informar?

En los comentarios, indica que tiene un host ESXi de cuatro núcleos dual y está ejecutando una máquina virtual de 8vCPU y catorce máquinas virtuales de 4vCPU.

Si este fuera mi entorno, consideraría que está excesivamente sobreaprovisionado . Como máximo, pondría de cuatro a seis invitados 4vCPU en ese hardware. (Esto supone que las máquinas virtuales en cuestión tienen una carga que requiere que tengan un conteo alto de vCPU).

Supongo que no conoce la regla de oro ... con VMware nunca debe asignar a una VM más núcleos de los que necesita. ¿Razón? VMware utiliza una programación conjunta algo estricta que dificulta que las máquinas virtuales obtengan tiempo de CPU a menos que haya tantos núcleos disponibles como la máquina virtual asignada. Es decir, una VM 4vCPU no puede realizar 1 unidad de trabajo a menos que haya 4 núcleos físicos abiertos en el mismo momento. En otras palabras, es arquitectónicamente mejor tener una VM de 1vCPU con una carga de CPU del 90%, y luego tener una VM de 2vCPU con una carga del 45% por núcleo.

Entonces ... SIEMPRE cree máquinas virtuales con un mínimo de vCPU, y solo agréguelas cuando sea necesario.

Para su situación, use Veeam para monitorear el uso de la CPU en sus invitados. Reduzca el recuento de vCPU en la mayor cantidad posible. Estaría dispuesto a apostar que podría caer a 2vCPU en casi todos sus invitados existentes de 4vCPU.

De acuerdo, si todas estas máquinas virtuales realmente tienen la carga de CPU para requerir el recuento de vCPU que tienen, entonces simplemente necesita comprar hardware adicional.

Los 127,835.94 milisegundos son una suma y necesita dividir por el tiempo de muestra para obtener los valores correctos de% RDY. Sin embargo, ahora parece que ya está obteniendo las lecturas correctas de% RDY. Puede llegar bastante alto con la relación vCPU a CPU física, pero no de la forma en que lo está haciendo.

Tiene demasiadas máquinas virtuales de vCPU cuádruple e incluso una máquina virtual de 8 vCPU. Hay algunas respuestas de calidad que ya analizan el tamaño correcto y algunas ramificaciones de no consolidar los ciclos a menos vCPU. Lo único que quería aclarar es que, si bien ya no es el caso de que una máquina virtual deba esperar a que esté disponible la cantidad de CPU físicas que es igual a su cantidad de vCPU antes de que se pueda procesar cualquier instrucción, es muy perjudicial tener un aprovisionamiento excesivo de esta magnitud con la relación de máquinas virtuales de múltiples vCPU a núcleos físicos. 64 vCPU en 8 núcleos supera con creces la relación máxima de 4 a 1. Supongo que tiene HT en estos procesadores, ¿entonces tiene 16 núcleos lógicos? Eso podría estar bien con 1 y 2 máquinas virtuales de vCPU que tienen una carga ligera, pero si tiene una carga pesada en las máquinas virtuales, sería difícil de lograr.

FYI Los procesadores HT no se usan en los cálculos de% de CPU utilizados, lo que significa que si tiene 32 núcleos lógicos ejecutándose a 2.4 Ghz en un servidor, tiene un 100% de uso cuando alcanza 38.4 GHz. Entonces, cuando vea que los promedios de carga muestran más de 1.0, es por eso.

Aquí hay un host ESXi que ejecuta una relación de CPU de 3.5 a 1 vCPU a CPU física (incluidos los núcleos HT) con un% RDY promedio de 3%.

11:13:49pm up 125 days  7:20, 1322 worlds, 110 VMs, 110 vCPUs; CPU load average: 1.34, 1.43, 1.37


  %USED    %RUN    %SYS   %WAIT %VMWAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT 
  13.51   15.87    0.50  580.17    0.03    4.67   66.47    0.29    0.00    0.00    0.00 
  15.24   18.64    0.43  491.54    0.04    4.65   63.70    0.43    0.00    0.00    0.00 
  13.44   16.40    0.44  494.10    0.02    4.33   66.24    0.48    0.00    0.00    0.00 
  13.75   16.30    0.51  494.26    0.32    4.32   66.06    0.35    0.00    0.00    0.00 
  17.56   20.72    0.58  489.35    0.04    4.31   60.76    0.45    0.00    0.00    0.00 
  13.82   16.43    0.50  494.12    0.07    4.31   66.26    0.26    0.00    0.00    0.00 
  13.65   16.81    0.49  493.81    0.03    4.21   65.93    0.37    0.00    0.00    0.00 
  13.73   16.51    0.42  493.63    0.09    4.06   66.24    0.29    0.00    0.00    0.00 
  13.89   16.37    0.55  580.61    0.04    3.95   66.69    0.28    0.00    0.00    0.00 
  14.02   17.00    0.33  494.11    0.03    3.93   66.10    0.29    0.00    0.00    0.00 
  13.44   15.84    0.49  495.17    0.04    3.87   67.24    0.27    0.00    0.00    0.00 
  13.59   15.84    0.50  580.27    0.04    3.81   67.24    0.44    0.00    0.00    0.00 
  17.10   19.86    0.50  490.97    0.04    3.74   62.21    0.39    0.00    0.00    0.00 
  13.32   15.77    0.50  495.34    0.03    3.73   67.47    0.27    0.00    0.00    0.00 
  13.43   16.15    0.48  494.95    0.05    3.72   67.09    0.38    0.00    0.00    0.00 
  13.44   16.47    0.49  580.88    0.04    3.72   66.81    0.40    0.00    0.00    0.00 
  13.71   17.00    0.29  494.13    0.03    3.71   66.26    0.37    0.00    0.00    0.00 
  17.34   20.41    0.39  490.50    0.05    3.70   61.70    0.37    0.00    0.00    0.00 
  13.42   16.19    0.50  495.07    0.03    3.66   67.15    0.38    0.00    0.00    0.00 
  13.56   16.23    0.48  494.97    0.03    3.60   67.12    0.30    0.00    0.00    0.00 
  14.95   17.53    0.42  578.82    0.09    3.57   65.72    0.35    0.00    0.00    0.00 
  13.44   16.07    0.56  581.14    0.04    3.54   67.34    0.40    0.00    0.00    0.00 
  17.19   21.27    0.37  575.41    0.04    3.44   61.08    0.51    0.00    0.00    0.00 
  13.57   16.99    0.30  580.64    0.01    3.37   66.69    0.38    0.00    0.00    0.00 
  13.79   16.25    0.43  495.25    0.04    3.35   67.39    0.39    0.00    0.00    0.00 
  11.90   14.67    0.30  496.86    0.02    3.31   69.00    0.36    0.00    0.00    0.00 
  17.13   19.28    0.56  491.83    0.03    3.30   63.26    0.48    0.00    0.00    0.00 
  14.01   16.17    0.50  495.56    0.01    3.30   67.66    0.39    0.00    0.00    0.00 
  16.86   20.16    0.57  491.19    0.05    3.20   62.44    0.43    0.00    0.00    0.00 
  14.94   17.46    0.42  580.05    0.08    3.16   66.24    0.40    0.00    0.00    0.00 
  14.56   16.94    0.36  494.86    0.08    3.14   66.91    0.42    0.00    0.00    0.00

......

Desde entonces, hemos instalado Veeam ONE, que ha arrojado bastante luz sobre dónde están nuestros problemas de rendimiento. Al mirar la pantalla Cuellos de botella de la CPU en Veeam ONE y luego usar la solución de problemas de una máquina virtual que ha dejado de responder: VMM y la comparación del uso de la CPU invitada como referencia, hemos descubierto dónde está nuestra gran cantidad de argumentos "inaceptables".

Un pequeño consejo que quería compartir específicamente es que en un caso no podría eliminar la contención de la CPU hasta que elimine la instantánea que estaba en la VM. Espero que esto ayude a alguien.