Desde hace un tiempo he estado tratando de descubrir por qué algunos de nuestros sistemas críticos para el negocio reciben informes de "lentitud" que van desde leves hasta extremas. Recientemente me fijé en el 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 a mi jefe también) los números que me informa. Para intentar 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 miradoeste 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 estuvo lista para ejecutarse, pero sufrió un retraso debido a una contención de programación de co-vCPU
al 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, se puede considerar que "no responde".
¿Te parece correcta esta traducción?
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" actualmente muestra un promedio de parada conjunta de CPU de127.835,94milisegundos!
¿Significa esto que, en promedio, las máquinas virtuales de este host tienen que esperar más de 2 minutos para tener tiempo de CPU?
Este host tiene dos CPU de 4 núcleos y tiene 1x8 CPU invitada y 14x4 CPU invitada.
Respuesta1
Puedo describir algunas de las experiencias que he tenido en esta área...
No creo que VMware haga un trabajo adecuado a la hora de educar a los clientes (o administradores) sobre las mejores prácticas, ni actualizan las mejores prácticas anteriores a medida que evolucionan sus productos. Esta pregunta es un ejemplo de cómo un concepto central como la asignación de vCPU no se comprende completamente. El mejor enfoque es comenzar poco a poco, 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, lo que produce 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 uninvitado único con 8 vCPU. No tiene sentido. Si necesita una máquina virtual tan grande, probablemente necesite un servidor más grande.
Por favor intentaTalla correctasus 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 una solución a 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 pruebas de ello. La RAM también puede ser un problema sise asigna demasiado a máquinas virtuales individuales.
Es posible monitorear esto. La métrica que estás buscando es "% de CPU lista". Puede acceder a esto desde el cliente vSphere seleccionando una VM y yendo a Performance> Overview> CPU Graph.
- Menos del 5% de CPU lista- Estás bien.
- 5-10% CPU lista- Vigila de cerca la actividad.
- Más del 10% de CPU lista- No es bueno.
Observe la línea amarilla en el gráfico siguiente.
¿Le importaría comprobar esto en las máquinas virtuales con problemas e informar?
Respuesta2
Usted indica en los comentarios que tiene un host ESXi de cuatro núcleos duales y que está ejecutando una máquina virtual de 8vCPU, ycatorceMáquinas virtuales de 4vCPU.
Si este fuera mi entorno, lo consideraríagravementesobreaprovisionado. Como máximo pondría de cuatro a seis invitados de 4vCPU en ese hardware. (Esto supone que las máquinas virtuales en cuestión tienen una carga que requiere que tengan un recuento de vCPU tan alto).
Supongo que no conoces la regla de oro... con VMware nunca debes 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 los asignados a la máquina virtual. Es decir, una VM de 4vCPU no puede realizar 1 unidad de trabajo a menos que haya 4 núcleos físicos abiertos al mismo tiempo. En otras palabras, desde el punto de vista arquitectónico, es mejor tener una máquina virtual de 1 vCPU con un 90 % de carga de CPU, que tener una máquina virtual de 2 vCPU con un 45 % de carga por núcleo.
Entonces... SIEMPRE cree máquinas virtuales con un mínimo de vCPU y agréguelas solo cuando se determine que es necesario.
Para su situación, utilice Veeam para monitorear el uso de CPU de sus invitados. Reduzca el número de vCPU tanto como sea posible. Estaría dispuesto a apostar a que podría reducir a 2vCPU en casi todos sus invitados de 4vCPU existentes.
Por supuesto, si todas estas máquinas virtuales realmente tienen la carga de CPU necesaria para requerir el recuento de vCPU que tienen, entonces simplemente necesitará comprar hardware adicional.
Respuesta3
Los 127.835,94 milisegundos son una suma y es necesario dividirlos por el tiempo de muestra para obtener los valores %RDY correctos. Sin embargo, parece que ya estás obteniendo las lecturas correctas de %RDY. Puede llegar bastante alto con la proporción de vCPU a CPU física, pero no de la forma en que lo hace.
Tiene demasiadas máquinas virtuales con cuatro vCPU e incluso una máquina virtual con 8 vCPU. Ya hay algunas respuestas de calidad que discuten el tamaño correcto y algunas ramificaciones de no consolidar los ciclos en menos vCPU. Lo único que quería aclarar es que, si bien ya no es cierto que una máquina virtual deba esperar a que esté disponible una cantidad de CPU físicas igual a su cantidad de vCPU antes de que se pueda procesar cualquier instrucción, es muy perjudicial. tener un sobreaprovisionamiento de esta magnitud con la proporción de máquinas virtuales con múltiples vCPU y núcleos físicos. 64 vCPU en 8 núcleos está mucho más allá de la proporción máxima de 4 a 1. Supongo que tiene HT en estos procesadores, por lo que tiene 16 núcleos lógicos. Eso podría estar bien con máquinas virtuales de 1 y 2 vCPU que tienen una carga ligera, pero si tiene una carga pesada en las máquinas virtuales, sería difícil de lograr.
Para su información, los procesadores HT no se utilizan en los cálculos de porcentaje de CPU utilizado, lo que significa que si tiene 32 núcleos lógicos ejecutándose a 2,4 Ghz en un servidor, tendrá un uso del 100 % cuando alcance los 38,4 GHz. Entonces, cuando vea que los promedios de carga muestran más de 1,0, ese es el motivo.
Aquí se muestra un host ESXi que ejecuta una proporción de 3,5 a 1 vCPU por CPU física (incluidos los núcleos HT) con un %RDY promedio del 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
......
Respuesta4
Desde entonces, instalamos Veeam ONE, lo que arrojó bastante luz sobre dónde están nuestros problemas de rendimiento. Mirando la pantalla CPU Bottlenecks en Veeam ONE y luego usandoSolución de problemas de una máquina virtual que dejó de responder: comparación de uso de VMM y CPU invitadaComo referencia, hemos descubierto dónde está gran parte de nuestro argumento "inaceptable".
Un pequeño consejo que quería compartir específicamente es que en un caso no pude eliminar la contención de la CPU hasta que eliminé la instantánea que estaba en la VM. Espero que esto ayude a alguien.