Si administra una infraestructura virtual basada en VMware vSphere (o en cualquier otro stack tecnológico), seguramente escucha a menudo que los usuarios se quejan: “¡La máquina virtual está funcionando lentamente!”. En esta serie de artículos, analizaré las métricas de rendimiento y explicaré qué y por qué puede estar ‘‘ralentizando’’ y cómo evitar que eso suceda.
Consideraré los siguientes aspectos del rendimiento de las máquinas virtuales:
- CPU,
- RAM,
- DISCO,
- Red.
Comenzaré con la CPU.
Para el análisis del rendimiento, necesitaremos:
- Contadores de rendimiento de vCenter – contadores de rendimiento cuyos gráficos se pueden visualizar a través del cliente de vSphere. La información de estos contadores está disponible en cualquier versión del cliente (el cliente “grueso” en C#, cliente web en Flex y cliente web en HTML5). En estos artículos utilizaremos capturas de pantalla del cliente en C#, simplemente porque se ven mejor en miniatura:)
- ESXTOP – una herramienta que se inicia desde la línea de comandos de ESXi. Con ella se pueden obtener valores de contadores de rendimiento en tiempo real o exportar esos valores por un período determinado a un archivo .csv para un análisis posterior. Más adelante hablaré de esta herramienta en detalle y proporcionaré algunos enlaces útiles a la documentación y artículos sobre el tema.
Un poco de teoría
En ESXi, cada vCPU (núcleo de la máquina virtual) es gestionado por un proceso separado, denominado world en la terminología de VMware. También hay procesos de servicio, pero desde el punto de vista del análisis de rendimiento de VM, son menos interesantes.
Un proceso en ESXi puede estar en uno de cuatro estados:
- Ejecutar – el proceso está realizando algún trabajo útil.
- Esperar – el proceso no está realizando ningún trabajo (idle) o está esperando entrada/salida.
- Costop – una condición que ocurre en máquinas virtuales multinúcleo. Se presenta cuando el planificador de CPU del hipervisor (ESXi CPU Scheduler) no puede programar la ejecución simultánea en los núcleos físicos del servidor de todos los núcleos activos de la máquina virtual. En el mundo físico, todos los núcleos del procesador funcionan en paralelo, la OS invitada dentro de la VM cuenta con un comportamiento similar, por lo que el hipervisor tiene que ralentizar los núcleos de la VM que tienen la capacidad de completar el ciclo más rápido. En las versiones modernas de ESXi, el planificador de CPU utiliza un mecanismo llamado co-scheduling relajado: el hipervisor mide la diferencia entre el núcleo
- Listo – un proceso entra en este estado cuando el hipervisor no puede asignar recursos para su ejecución. Valores altos de ready pueden causar problemas de rendimiento en la VM.
Contadores clave de rendimiento de la CPU de la máquina virtual
Uso de CPU, % Muestra el porcentaje de uso de la CPU durante un período determinado.
¿Cómo analizar? Si la VM utiliza la CPU consistentemente al 90% o hay picos hasta el 100%, tenemos un problema. Los problemas pueden manifestarse no solo en el rendimiento 'lento' de la aplicación dentro de la VM, sino también en la inaccesibilidad de la VM a través de la red. Si el sistema de monitoreo muestra que la VM se cae periódicamente, preste atención a los picos en el gráfico de Uso de CPU.
Hay una alarma estándar que muestra la carga de CPU de la máquina virtual:
¿Qué hacer? Si el Uso de CPU de la VM está constantemente por encima del límite, se puede considerar aumentar la cantidad de vCPU (desafortunadamente, esto no siempre ayuda) o migrar la VM a un servidor con procesadores más potentes.
Uso de CPU en Mhz
En los gráficos de vCenter, el Uso está en % y se puede ver solo para toda la máquina virtual, no hay gráficos por núcleos individuales (en Esxtop hay valores en % por núcleo). Se puede ver el Uso en MHz para cada núcleo.
¿Cómo analizar? A veces, la aplicación no está optimizada para arquitecturas multinúcleo: utiliza al 100% solo un núcleo, mientras que los demás se quedan inactivos sin carga. Por ejemplo, con la configuración predeterminada de respaldo, MS SQL inicia el proceso solo en un núcleo. Como resultado, la copia de seguridad se ralentiza no debido a la baja velocidad de los discos (que es lo que el usuario se quejó inicialmente), sino porque el procesador no puede manejar la carga. El problema se solucionó al cambiar los parámetros: la copia de seguridad comenzó a ejecutarse en paralelo en varios archivos (y, por lo tanto, en varios procesos).
Ejemplo de carga desigual en los núcleos.
También puede ocurrir una situación (como en el gráfico anterior), donde los núcleos están sobrecargados de manera desigual y en algunos de ellos hay picos del 100%. Al igual que con la carga de solo un núcleo, la alarma de uso de CPU no se activará (es global en toda la VM), pero habrá problemas de rendimiento.
¿Qué hacer? Si el software en la máquina virtual carga los núcleos de manera desigual (utiliza solo un núcleo o algunos núcleos), no tiene sentido aumentar su número. En tal caso, es mejor mover la VM a un servidor con procesadores más potentes.
También se puede intentar verificar la configuración de energía en la BIOS del servidor. Muchos administradores activan en la BIOS el modo de alto rendimiento, desactivando así las tecnologías de ahorro de energía C-states y P-states. En los procesadores Intel modernos se utiliza la tecnología Turbo Boost, que aumenta la frecuencia de núcleos individuales del procesador a expensas de otros núcleos. Pero solo funciona cuando las tecnologías de ahorro de energía están habilitadas. Si las desactivamos, el procesador no puede reducir el consumo de energía de los núcleos que no están bajo carga.
VMware recomienda no desactivar las tecnologías de ahorro de energía en los servidores, sino elegir modos que transfieran el máximo control del consumo energético al hipervisor. Además, en la configuración de energía del hipervisor, se debe seleccionar el modo de alto rendimiento.
Si en su infraestructura hay VMs separadas (o núcleos de VM) que requieren una mayor frecuencia de CPU, una configuración correcta del consumo de energía puede mejorar significativamente su rendimiento.
CPU Ready (Preparación)
Si el núcleo de la VM (vCPU) está en estado Ready, no está realizando trabajo útil. Este estado ocurre cuando el hipervisor no encuentra un núcleo físico disponible al que asignar el proceso vCPU de la máquina virtual.
¿Cómo analizar? Normalmente, si los núcleos de la máquina virtual están en estado Ready más del 10% del tiempo, notarás problemas de rendimiento. En resumen, más del 10% del tiempo la VM está esperando la disponibilidad de recursos físicos.
En vCenter, puedes ver 2 contadores relacionados con CPU Ready:
- Readiness,
- Ready.
Los valores de ambos contadores se pueden ver tanto para toda la VM como para núcleos individuales.
Readiness muestra el valor en porcentaje, pero solo en tiempo real (datos de la última hora, intervalo de medición de 20 segundos). Este contador es mejor utilizarlo solo para buscar problemas "in situ".
Los valores del contador Ready también se pueden ver en una perspectiva histórica. Esto es útil para establecer patrones y para un análisis más profundo del problema. Por ejemplo, si la máquina virtual comienza a tener problemas de rendimiento a cierta hora, se puede correlacionar los intervalos elevados del valor de CPU Ready con la carga total en el servidor donde esta VM se está ejecutando y tomar medidas para reducir la carga (si DRS no lo ha hecho).
A diferencia de Readiness, el valor de Ready se muestra en milisegundos, no en porcentaje. Este contador es del tipo Summation, es decir, muestra cuánto tiempo durante el periodo de medición el núcleo de la VM estuvo en estado Ready. Este valor se puede convertir a porcentaje mediante una fórmula sencilla:
(valor de suma de CPU ready / (intervalo de actualización por defecto del gráfico en segundos * 1000)) * 100 = CPU ready %
Por ejemplo, para la VM en el gráfico a continuación, el valor pico de Ready para toda la máquina virtual será el siguiente:
Al calcular el valor de Ready en porcentaje, debes prestar atención a dos aspectos:
- El valor de Ready para toda la VM es la suma de Ready de los núcleos.
- El intervalo de medición. Para tiempo real, esto es 20 segundos, y para los gráficos diarios, por ejemplo, es de 300 segundos.
Durante la solución activa de problemas, es fácil pasar por alto estos puntos simples y perder tiempo valioso resolviendo problemas inexistentes.
Calcularemos el valor de Ready basado en los datos del gráfico a continuación. (324474/(20*1000))*100 = 1622% para toda la VM. Si consideramos los núcleos, la situación no parece tan grave: 1622/64 = 25% por núcleo. En este caso, detectar un problema es bastante sencillo: el valor de Ready es poco realista. Sin embargo, si se trata de un 10-20% para toda la VM con varios núcleos, el valor por núcleo podría estar dentro de un rango normal.
¿Qué hacer? Un alto valor de Ready indica que el servidor carece de recursos de CPU para el funcionamiento normal de las máquinas virtuales. En tal situación, la única opción es reducir la sobreasignación de CPU (vCPU:pCPU). Es evidente que esto se puede lograr reduciendo las especificaciones de las VMs existentes o migrando algunas VMs a otros servidores.
Co-stop
¿Cómo analizar? Este contador también tiene un tipo de suma y se traduce en porcentajes de forma similar a Ready:
(Valor de suma de co-stop de CPU / (intervalo de actualización por defecto en segundos * 1000)) * 100 = % de co-stop de CPU
Aquí también es importante prestar atención al número de núcleos en la VM y al intervalo de medición.
En estado de co-stop, un núcleo no realiza trabajo útil. Con la elección adecuada del tamaño de la VM y una carga normal en el servidor, el contador de co-stop debería ser cercano a cero.
En este caso, la carga es claramente anormal :)
¿Qué hacer? Si en un hipervisor hay varias VMs con un alto número de núcleos y existe sobreasignación de CPU, el contador de co-stop puede aumentar, lo que llevará a problemas de rendimiento en esas VMs.
El co-stop también aumentará si se utilizan hilos en un solo núcleo físico del servidor con hyper-threading activado para los núcleos activos de una VM. Esta situación puede ocurrir, por ejemplo, si la VM tiene más núcleos que los que existen físicamente en el servidor donde se ejecuta, o si la VM tiene activada la configuración 'preferHT'. Se puede leer más sobre esta configuración. .
Para evitar problemas de rendimiento en la VM debido a un alto co-stop, elija el tamaño de la VM según las recomendaciones del proveedor de software que corre en esa VM y según las capacidades del servidor físico donde se ejecuta la VM.
No añada núcleos de reserva, esto puede causar problemas de rendimiento no solo en la propia VM, sino también en sus vecinas en el servidor.
Otras métricas útiles de CPU
Ejecutar – cuánto tiempo (ms) durante el periodo de medición vCPU estuvo en estado RUN, es decir, realizando trabajo útil.
Idle – cuánto tiempo (ms) durante el período de medición estuvo el vCPU en estado de inactividad. Altos valores de Idle no son un problema, simplemente el vCPU no tenía «nada que hacer».
Esperar – cuánto tiempo (ms) durante el período de medición estuvo el vCPU en estado de espera. Dado que este contador incluye IDLE, altos valores de Wait tampoco indican un problema. Sin embargo, si el IDLE es bajo con un alto Wait, significa que la VM estaba esperando que se completaran las operaciones de entrada/salida, lo que puede indicar un problema de rendimiento con el disco duro o algunos dispositivos virtuales de la VM.
Máxima limitada – cuánto tiempo (ms) durante el período de medición estuvo el vCPU en estado Ready debido a un límite de recursos establecido. Si el rendimiento es inexplicablemente bajo, es útil verificar el valor de este contador y el límite de CPU en la configuración de la VM. La VM puede tener límites establecidos que usted no conoce. Por ejemplo, esto ocurre cuando la VM se clonó de una plantilla donde se estableció un límite de CPU.
Espera de Swap – cuánto tiempo durante el período de medición estuvo el vCPU esperando operaciones con el Swap de VMkernel. Si los valores de este contador son mayores que cero, la VM definitivamente tiene problemas de rendimiento. Hablaremos más sobre SWAP en el artículo sobre contadores de memoria.
ESXTOP
Si los contadores de rendimiento en vCenter son buenos para analizar datos históricos, un análisis operativo del problema se realiza mejor en ESXTOP. Aquí todos los valores se presentan listos (no es necesario traducir nada), y el período mínima de medición es de 2 segundos.
La pantalla de ESXTOP por CPU se invoca con la tecla «c» y se ve de la siguiente manera:
Para mayor comodidad, se pueden dejar solo los procesos de máquinas virtuales, presionando Shift-V.
Para ver las métricas de los núcleos individuales de la VM, presione «e» e ingrese el GID de la VM de interés (30919 en la captura de pantalla a continuación):
Haré un breve recorrido por las columnas que se presentan por defecto. Se pueden agregar columnas adicionales presionando «f».
NWLD (Número de Mundos) – número de procesos en el grupo. Para expandir el grupo y ver métricas para cada proceso (por ejemplo, para cada núcleo de una VM multicore), presione “e”. Si hay más de un proceso en el grupo, los valores de las métricas para el grupo son iguales a la suma de las métricas de los procesos individuales.
%USED – cuánto ciclo de CPU utiliza el proceso o grupo de procesos del servidor.
%RUN – cuánto tiempo durante el periodo de medición el proceso estuvo en estado RUN, es decir, realizando trabajo útil. Se diferencia del %USED en que no tiene en cuenta el hyper-threading, el escalado de frecuencia y el tiempo dedicado a tareas del sistema (%SYS).
%SYS – tiempo dedicado a tareas del sistema, por ejemplo: manejo de interrupciones, entrada/salida, trabajo de red, etc. El valor puede ser alto si la VM tiene una gran cantidad de entrada/salida.
%OVRLP – cuánto tiempo el núcleo físico, en el que se está ejecutando el proceso de la VM, ha dedicado a tareas de otros procesos.
Estos datos de métricas se relacionan entre sí de la siguiente manera:
%USED = %RUN + %SYS - %OVRLP.
Normalmente, la métrica %USED es más informativa.
%WAIT – cuánto tiempo durante el periodo de medición el proceso estuvo en estado Wait. Incluye IDLE.
%IDLE – cuánto tiempo durante el periodo de medición el proceso estuvo en estado IDLE.
%SWPWT – cuánto tiempo durante el periodo de medición el vCPU esperó operaciones con VMkernel Swap.
%VMWAIT – cuánto tiempo durante el periodo de medición el vCPU estuvo en estado de espera de un evento (normalmente entrada/salida). No hay un contador equivalente en vCenter. Valores altos indican problemas de entrada/salida en la VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Si la VM no utiliza VMkernel Swap, al analizar problemas de rendimiento es recomendable observar %VMWAIT, ya que esta métrica no toma en cuenta el tiempo cuando la VM no estaba haciendo nada (%IDLE).
%RDY – cuánto tiempo durante el periodo de medición el proceso estuvo en estado Ready.
%CSTP – cuánto tiempo durante el periodo de medición el proceso estuvo en estado costop.
%MLMTD – cuánto tiempo durante el periodo de medición el vCPU estuvo en estado Ready debido a un límite de recursos establecido.
%WAIT + %RDY + %CSTP + %RUN = 100% – el núcleo de la VM está siempre en alguno de estos cuatro estados.
CPU en el hipervisor
En vCenter también hay contadores de rendimiento de CPU para el hipervisor, pero no son de un interés particular; simplemente son la suma de los contadores de todas las VMs en el servidor.
Es más conveniente observar el estado de la CPU en el servidor en la pestaña Resumen:
Para el servidor, al igual que para la máquina virtual, hay una alarma estándar:
Con una alta carga de CPU en el servidor, las VMs que funcionan en él comienzan a tener problemas de rendimiento.
En ESXTOP, los datos de carga del CPU del servidor se presentan en la parte superior de la pantalla. Además de la carga estándar del CPU, que es poco informativa para los hipervisor, hay otras tres métricas:
UTILIZACIÓN DEL NÚCLEO (%) – carga del núcleo físico del servidor. Este contador muestra cuánto tiempo, durante el periodo de medición, el núcleo realizó trabajo.
UTILIZACIÓN PCPU (%) – si está habilitado el hyper-threading, cada núcleo físico tiene dos hilos (PCPU). Esta métrica muestra cuánto tiempo cada hilo realizó trabajo.
USO PCPU (%) – lo mismo que UTILIZACIÓN PCPU (%), pero tiene en cuenta el escalado de frecuencia (ya sea la disminución de la frecuencia del núcleo para ahorrar energía o el aumento de la frecuencia del núcleo gracias a la tecnología Turbo Boost) y el hyper-threading.
PCPU_USED% = PCPU_UTIL% * frecuencia efectiva del núcleo / frecuencia nominal del núcleo.
En esta captura de pantalla, para algunos núcleos, debido al funcionamiento de Turbo Boost, el valor USADO supera el 100%, ya que la frecuencia del núcleo es más alta que la nominal.
Un par de palabras sobre cómo se tiene en cuenta el hyper-threading. Si los procesos se ejecutan el 100% del tiempo en ambos hilos del núcleo físico del servidor, y el núcleo funciona a la frecuencia nominal, entonces:
- LA UTILIZACIÓN DEL NÚCLEO para el núcleo será del 100%,
- LA UTILIZACIÓN PCPU para ambos hilos será del 100%,
- EL USO PCPU para ambos hilos será del 50%.
Si ambos hilos no trabajaron el 100% del tiempo durante el periodo de medición, entonces en aquellos periodos en que los hilos trabajaron en paralelo, el USO PCPU para los núcleos se divide entre dos.
En ESXTOP también hay una pantalla con los parámetros de consumo de energía del CPU del servidor. Aquí se puede ver si el servidor utiliza tecnologías de ahorro de energía: C-states y P-states. Se accede con la tecla «p»:
Problemas estándar de rendimiento del CPU
Por último, repasaré las causas típicas de los problemas de rendimiento del CPU de la VM y daré breves consejos sobre su solución:
Falta de frecuencia nominal del núcleo. Si no hay posibilidad de trasladar la VM a núcleos más potentes, se puede intentar cambiar la configuración de energía para que Turbo Boost funcione de manera más efectiva.
Dimensionamiento incorrecto de la VM (demasiados pocos/muchos núcleos). Si se colocan pocos núcleos, habrá una alta carga de CPU en la VM. Si se colocan muchos, se experimentará un alto co-stop.
Gran sobreasignación de CPU en el servidor. Si en la VM hay un alto Ready, disminuya la sobreasignación de CPU.
Topología NUMA incorrecta en grandes VMs. La topología NUMA que ve la VM (vNUMA) debe corresponder a la topología NUMA del servidor (pNUMA). Sobre el diagnóstico y las posibles soluciones a este problema, se ha escrito, por ejemplo, en el libro . Si no deseas profundizar y no tienes restricciones de licencia sobre el sistema operativo instalado en la VM, crea en la VM muchos sockets virtuales con un núcleo cada uno. No perderás mucho 🙂
Con esto concluyo sobre la CPU. Haz preguntas. En la próxima parte hablaré sobre la memoria RAM.
Enlaces útiles
Fuente: habr.com
