En un entorno de VMWare ESXi es habitual que no tengamos una correlación
1:1 entre CPUs físicas y CPUs virtuales asignadas a las VMs del host ESXi.
Explicado de otra forma: El host VMWare ESXi, es habitual que tenga menos CPUs físicas que CPUs virtuales asignadas a VMs ya que el administrador de la infraestructura virtual acostumbra a situar muchas VMs en cada host VMWare ESXi.
Según VMWare la correlación entre CPUs virtuales (vCPU) y CPUs físicas no debería superar: 5:1, concretamente, nos indica lo siguiente:
La correlación (CPU virtual:CPU física):
- Entre 1:1 y 3:1: No hay problemas.
- Entre 3:1 y 5:1: Pueden empezar los problemas de rendimiento.
- Superior a 6:1: Empiezan los problemas.
Se entienden como CPUs físicas la suma de sockets, cores y hyper-threading.
Bien, en los casos que se sobrepasa la correlación 1:1 entre CPUs físicas y CPUs virtuales, entra en juego el scheduler.
El scheduler se encarga de encolar las peticiones de CPUs físicas por parte de las CPUs virtuales de las VMs.
Cuando tenemos problemas de rendimiento a nivel de CPU, puede ser que el problema venga por que se pida a un ritmo demasiado intenso recursos de CPU física por parte de las VMs.
La forma de ver si este es el problema, es utilizando la métrica CPU Ready.
El CPU Ready es una métrica que nos indica el tiempo de espera de las vCPU a que estén disponibles CPUs físicas.
El valor de CPU ready: Contra más alto, peor:
Como norma general:
* 5% de CPU Ready: Normal.
* Entre 5% y 10%: Malo.
* Superior al 10%: Muy malo.
No confundir el parámetro CPU Ready con CPU Usage.
CPU usage, nos indica el uso de CPU de la VM en el momento que estamos mirando la métrica.
Veamos como obtener el valor de CPU Ready:
Para obtener la métrica de CPU Ready, podemos utilizar VSphere client o bien ESXTOP desde SSH.
- Con VSphere Client, la métrica será presentada en milisegundos.
- Con ESXTOP, la métrica será presentada en tanto por ciento.
Para pasar de milisegundos a porcentaje, podemos utilizar la siguiente formula:
(X ms / 20.000 ms) * 100 = %
Por ejemplo, imaginemos que vía VSphere client, vemos que la métrica de CPU Ready es de: 400ms
Para pasar a porcentaje, seria:
(400ms / 20.000ms) *100 = 2% de CPU Ready.
VSphere Client: Vista de cómo añadir la métrica CPU Ready:
Pestaña "Performance", "Chart Options", "CPU", en el apartado "Counters", veremos: "Ready"
ESXTOP: Vista de cómo ver la métrica CPU Ready:
Conectamos vía SSH al host y examinamos la columna %RDY y veremos el tanto por ciento de CPU Ready para cada VM.
Hemos de tener en cuenta que el %RDY es por cada CPU virtual (vCPU), esto significa que si por ejemplo disponemos de una VM con 4 vCPU, esta puede llegar hasta un %RDY de 400%.
Dicho de otra forma, el tanto por ciento de CPU Ready sobre una VM, es distinto dependiendo de las vCPU que tenga configurada la VM.
Imaginemos que:
- Disponemos de una VM con 1 vCPU con un CPU Ready de un 10%, esto significaría que ya estamos teniendo problemas de rendimiento.
En cambio, imaginemos que:
- Disponemos de una VM con 8 vCPU con un CPU Ready de un 10%, esto significaría que el % de CPU Ready que toca por cada vCPU es de 10 dividido entre 8: 1,25%. Un CPU Ready bajo.
Tenemos un CPU Ready alto: ¿Qué podemos hacer?
La solución para salir del paso es mover las VMs a otros hosts ESXi para liberar recursos de CPU, por ejemplo, utilizando vMotion.
Para evitar que este problema vuelva a suceder, podemos trabajar en las siguientes medidas:
1) Este punto explica la afirmación: En según que entornos, asignar más vCPU a una VM, puede empeorar el rendimiento de CPU.
Repasar las vCPUs asignadas a las VMs: Si tenemos VMs con muchas vCPUs tendremos una demanda superior de CPUs físicas, por lo tanto, un CPU Ready superior, por lo tanto, mayor encolamiento de peticiones de CPU física, por lo tanto, peor rendimiento.
2) Repasar la correlación CPUs virtuales y CPUs físicas: Hay que tener en cuenta que el ratio no debería superar el 5:1, siendo recomendado estar por debajo, por ejemplo: 4:1.
3) Situar las VMs en los hosts VMWare ESXi, repartiendo la carga de CPU: VMs con uso intensivo de CPU, situarlas en hosts VMWare ESXi distintos.
4) En grandes entornos, con multitud de hosts y VMs: Podemos automatizar el punto anterior utilizando DRS para mover las VMs de host ESXi.
5) Asegurarse que disponemos del Hyperthreading activado en las opciones de la BIOS del host VMWare ESXi: Dispondremos de cores extra para repartir a vCPUs de VMs.
Muy útil, gracias
ResponderEliminarBuenas,
ResponderEliminarEl articulo tiene tiempo pero me ha servido para problemas actuales. Gran trabajo!
Una pregunta, ¿las pCPU es sin contar con HT? Por ejemplo, si tienes un host con 16 procesadores lógicos (dos sockets), serían 8 pCPU verdad? y otra pregunta.
A la hora de asignar los vCPU en una máquina para este host, ¿la asignación correcta seria como máximo 8 vcpu (Núcleos por socket: 8 , Sockets: 1 o Núcleos por socket: 4 , Sockets: 2)
Espero tu respuesta crack.
Como siempre un placer leerte.
Saludos!
Hola Antonio,
EliminarGracias por tus palabras.
Te contesto a tus dos preguntas:
- El Hyperthreading no proporciona un segundo núcleo completo para cada núcleo primario por tanto es mejor no contarlo para hacer el cálculo. Igualmente a efectos prácticos, el Hyperthreading ayuda para que no eleve el CPU Ready pero no se puede contar como un pCPU completo.
- La asignación de vCPU es la suma de sockets virtuales y cores virtuales, de hecho ESXi ya te dice sobre una VM cuantas vCPU tiene asignadas.
Un saludo,
Xavi.
Gracias a ti!
EliminarPor último, si estas mirando la gráfica del ultimo dia que hay que dividirlo entre los cores o eso es solo si lo ves en tiempo real con el esxtop. Te pongo ejemplo:
Máquina con 170000 ms en el último día de máximo.
170000 / 300000 * 100 = 56,6 %
¿Eso hay que dividirlo entre 12 vcpu que tiene la máquina o ahí ya no?
Muchas gracias de nuevo!
Hola Antonio,
EliminarPara hacer el cálculo, una forma muy sencilla para verlo a nivel de VM es utilizar el esxtop y ver el % de CPUready, es decir la columna %RDY y dividirlo por el número de vCPU.
Fíjate en lo que indico en el post: "Hemos de tener en cuenta que el %RDY es por cada CPU virtual (vCPU), esto significa que si por ejemplo disponemos de una VM con 4 vCPU, esta puede llegar hasta un %RDY de 400%."
Un saludo,
Xavi.
Buenas de nuevo,
EliminarSi, eso me ha quedado claro, pero el problema es que estoy viendo una gráfica del pasado. El ready actual no tiene nada que ver con ese día, por eso te preguntaba. No es lo mismo 56% que 4.6% de ready.
Cuando lo miré el filtro estaba como "Last day".
Ya me dices.
Saludos y gracias de nuevo!
Hola Antonio,
EliminarSí, el valor de CPU Ready siempre se ha de dividir por el número de vCPU que tiene la VM.
Igualmente un 4,6% de CPU Ready ya se está acercando a valores malos.
Si te vuelve a pasar el caso que explicas, puedes utilizar el esxtop en modo replay, es muy útil para ver a posterioridad con esxtop lo que ocurrió en el pasado:
https://www.sysadmit.com/2016/06/vmware-esxi-esxtop-modo-replay.html
Un saludo,
Xavi.