Si administra una infraestructura virtual basada en VMware vSphere (o cualquier otra pila de tecnología), es probable que a menudo escuche quejas de los usuarios: "¡La máquina virtual es lenta!". En esta serie de artículos, analizaré las métricas de rendimiento y le diré qué y por qué "se ralentiza" y cómo asegurarse de que no se "ralentice".
Consideraré los siguientes aspectos del rendimiento de la máquina virtual:
- UPC,
- RAM,
- disco,
- Red.
Voy a empezar con la CPU.
Para el análisis de rendimiento necesitamos:
- Contadores de rendimiento de vCenter – contadores de rendimiento, cuyos gráficos se pueden ver a través de vSphere Client. La información sobre estos contadores está disponible en cualquier versión del cliente (cliente “grueso” en C#, cliente web en Flex y cliente web en HTML5). En estos artículos, usaremos capturas de pantalla del cliente C#, solo porque se ven mejor en miniatura :)
- ESXTOP es una utilidad que se ejecuta desde la línea de comandos de ESXi. Con su ayuda, puede obtener los valores de los contadores de rendimiento en tiempo real o cargar estos valores durante un período determinado en un archivo .csv para su posterior análisis. A continuación, le contaré más sobre esta herramienta y le proporcionaré algunos enlaces útiles a documentación y artículos sobre el tema.
Un poco de teoría
En ESXi, un proceso independiente es responsable del funcionamiento de cada vCPU (núcleo de máquina virtual), mundo en la terminología de VMware. También hay procesos de servicio, pero desde el punto de vista del análisis del rendimiento de la VM, son menos interesantes.
Un proceso en ESXi puede estar en uno de cuatro estados:
- Ejecutar El proceso está haciendo un trabajo útil.
- Esperar - el proceso no realiza ningún trabajo (inactivo) o espera entrada/salida.
- Costo - un estado que ocurre en máquinas virtuales multinúcleo. Ocurre cuando el programador de CPU del hipervisor (ESXi CPU Scheduler) no puede programar todos los núcleos de máquinas virtuales activos para que se ejecuten en los núcleos físicos del servidor al mismo tiempo. En el mundo físico, todos los núcleos del procesador se ejecutan en paralelo, el sistema operativo invitado dentro de la VM espera un comportamiento similar, por lo que el hipervisor tiene que ralentizar los núcleos de la VM, que tienen la oportunidad de terminar el ciclo más rápido. En las versiones modernas de ESXi, el programador de la CPU utiliza un mecanismo llamado programación conjunta relajada: el hipervisor calcula la brecha entre el núcleo de la máquina virtual "más rápido" y el "más lento" (sesgo). Si la brecha excede un cierto umbral, el núcleo "rápido" ingresa al estado de costop. Si los núcleos de las máquinas virtuales pasan mucho tiempo en este estado, puede causar problemas de rendimiento.
- Listo! – el proceso entra en este estado cuando el hipervisor no puede asignar recursos para su ejecución. Los valores altos de preparación pueden causar problemas de rendimiento de la máquina virtual.
Contadores de rendimiento de la CPU de la máquina virtual principal
Uso de CPU, %. Muestra el porcentaje de uso de la CPU durante el período especificado.
¿Cómo analizar? Si la VM usa constantemente la CPU al 90 % o hay picos de hasta el 100 %, entonces tenemos un problema. Los problemas pueden expresarse no solo en el funcionamiento "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 máquina virtual se cae periódicamente, preste atención a los picos en el gráfico de uso de la CPU.
Hay una alarma estándar que muestra la carga de la CPU de la máquina virtual:
¿Qué hacer? Si el uso de la CPU de la máquina virtual se sale de escala constantemente, puede pensar en aumentar la cantidad de vCPU (lamentablemente, esto no siempre ayuda) o mover la máquina virtual a un servidor con procesadores más eficientes.
Uso de CPU en Mhz
En los gráficos en vCenter, el Uso en % solo se puede ver para toda la máquina virtual, no hay gráficos para núcleos individuales (en Esxtop, hay valores en % para núcleos). Para cada núcleo, puede ver el uso en MHz.
¿Cómo analizar? Sucede que una aplicación no está optimizada para una arquitectura multinúcleo: usa solo un núcleo al 100%, y el resto están inactivos sin carga. Por ejemplo, con la configuración de copia de seguridad predeterminada, MS SQL inicia el proceso en un solo núcleo. Como resultado, la copia de seguridad se ralentiza no por la baja velocidad de los discos (esto es de lo que se quejó inicialmente el usuario), sino porque el procesador no puede hacer frente. El problema se resolvió cambiando los parámetros: la copia de seguridad comenzó a ejecutarse en paralelo en varios archivos (respectivamente, en varios procesos).
Un ejemplo de carga desigual de núcleos.
También hay una situación (como en el gráfico anterior) en la que los núcleos se cargan de manera desigual y algunos de ellos tienen picos del 100 %. Al igual que con la carga de un solo núcleo, la alarma de uso de la CPU no funcionará (está en toda la máquina virtual), pero habrá problemas de rendimiento.
¿Qué hacer? Si el software de la máquina virtual carga los núcleos de manera desigual (utiliza solo un núcleo o parte de los núcleos), no tiene sentido aumentar su número. En este caso, es mejor mover la VM a un servidor con procesadores más eficientes.
También puede intentar verificar la configuración de energía en el BIOS del servidor. Muchos administradores activan el modo de alto rendimiento en el BIOS y, por lo tanto, desactivan las tecnologías de ahorro de energía de los estados C y P. Los procesadores Intel modernos utilizan la tecnología Turbo Boost, que aumenta la frecuencia de los núcleos de procesadores individuales a expensas de otros núcleos. Pero solo funciona cuando las tecnologías de ahorro de energía están habilitadas. Si los deshabilitamos, entonces el procesador no puede reducir el consumo de energía de los núcleos que no están cargados.
VMware recomienda no deshabilitar las tecnologías de ahorro de energía en los servidores, sino elegir modos que brinden la máxima administración de energía al hipervisor. Al mismo tiempo, en la configuración de consumo de energía del hipervisor, debe seleccionar Alto rendimiento.
Si tiene máquinas virtuales individuales (o núcleos de máquinas virtuales) en su infraestructura que requieren una mayor frecuencia de CPU, configurar correctamente el consumo de energía puede mejorar significativamente su rendimiento.
CPU listo (preparación)
Si el núcleo de la VM (vCPU) está en estado Listo, no realiza un trabajo útil. Esta condición ocurre cuando el hipervisor no encuentra un núcleo físico libre al que se pueda asignar el proceso vCPU de la máquina virtual.
¿Cómo analizar? Por lo general, si los núcleos de una máquina virtual están en estado Listo durante más del 10 % del tiempo, notará problemas de rendimiento. En pocas palabras, más del 10 % del tiempo la máquina virtual espera la disponibilidad de los recursos físicos.
En vCenter, puede ver 2 contadores relacionados con CPU Ready:
- preparación,
- En Sus Marcas.
Los valores de ambos contadores se pueden ver tanto para la máquina virtual completa como para los núcleos individuales.
La preparación muestra el valor inmediatamente como un porcentaje, pero solo en tiempo real (datos de la última hora, intervalo de medición de 20 segundos). Este contador se usa mejor solo para encontrar problemas en la persecución.
Los valores de contador listos 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 una VM comienza a tener problemas de rendimiento en un momento determinado, puede comparar los intervalos de mantenimiento de CPU Ready con la carga general en el servidor donde se ejecuta la VM y tomar medidas para reducir la carga (si falla DRS).
Ready, a diferencia de Readiness, no se muestra en porcentajes, sino en milisegundos. Este es un contador del tipo Summation, es decir, muestra cuánto tiempo durante el período de medición el núcleo de la VM estuvo en estado Listo. Puede convertir este valor a un porcentaje usando una fórmula simple:
(Valor de suma de CPU preparada / (intervalo de actualización predeterminado del gráfico en segundos * 1000)) * 100 = % de CPU preparada
Por ejemplo, para la VM en el siguiente gráfico, el valor máximo de Listo para toda la máquina virtual sería:
Al calcular el valor Listo como un porcentaje, debe prestar atención a dos puntos:
- El valor Listo en toda la máquina virtual es la suma de Listo en todos los núcleos.
- Intervalo de medición. Para tiempo real, esto es 20 segundos y, por ejemplo, en gráficos diarios, esto es 300 segundos.
Con la resolución activa de problemas, estos momentos simples pueden perderse fácilmente y perder un tiempo valioso resolviendo problemas inexistentes.
Calculemos Ready según los datos del siguiente gráfico. (324474/(20*1000))*100 = 1622% para toda la VM. Si nos fijamos en los núcleos, no da tanto miedo: 1622/64 = 25% por núcleo. En este caso, el problema es bastante fácil de detectar: el valor Listo no es realista. Pero si hablamos de un 10-20% para toda la máquina virtual con varios núcleos, entonces para cada núcleo el valor puede estar dentro del rango normal.
¿Qué hacer? Un valor Listo alto indica que el servidor no tiene suficientes recursos de procesador para el funcionamiento normal de las máquinas virtuales. En tal situación, solo queda reducir la sobresuscripción por procesador (vCPU:pCPU). Obviamente, esto se puede lograr reduciendo los parámetros de las VM existentes o migrando parte de la VM a otros servidores.
Co-parada
¿Cómo analizar? Este contador también es del tipo Sumatorio y se convierte a porcentajes de la misma forma que Listo:
(Valor de suma de parada conjunta de CPU / (intervalo de actualización predeterminado del gráfico en segundos * 1000)) * 100 = % de parada conjunta de CPU
Aquí también debe prestar atención a la cantidad de núcleos por VM y el intervalo de medición.
En el estado costop, el núcleo no realiza ningún trabajo útil. Con el tamaño adecuado de la máquina virtual y la carga normal del servidor, el contador de paradas conjuntas debería estar cerca de cero.
En este caso, la carga es claramente anormal :)
¿Qué hacer? Si varias máquinas virtuales con una gran cantidad de núcleos se ejecutan en el mismo hipervisor y hay una sobresuscripción por parte de la CPU, entonces el contador de paradas conjuntas puede aumentar, lo que generará problemas con el rendimiento de estas máquinas virtuales.
Además, la detención conjunta aumentará si se usan subprocesos para núcleos activos de una VM en un núcleo de servidor físico con Hyper-Treading habilitado. Esta situación puede ocurrir, por ejemplo, si la VM tiene más núcleos de los que tiene físicamente en el servidor donde se ejecuta, o si la configuración "preferHT" está habilitada para la VM. Puede leer acerca de esta configuración. .
Para evitar problemas de rendimiento de la VM debido a un alto número de paradas conjuntas, dimensione la VM de acuerdo con las recomendaciones del fabricante para el software que se ejecuta en esa VM y las capacidades del servidor físico donde se ejecuta la VM.
No agregue núcleos en reserva, esto puede causar problemas de rendimiento no solo para la máquina virtual en sí, sino también para sus vecinos en el servidor.
Otras métricas de CPU útiles
Ejecutar – cuánto tiempo (ms) durante el período de medición la vCPU estuvo en el estado RUN, es decir, realmente realizó un trabajo útil.
Idle – cuánto tiempo (ms) durante el período de medición la vCPU estuvo en estado inactivo. Los valores altos de inactividad no son un problema, es solo que la vCPU no tenía "nada que hacer".
Esperar – cuánto tiempo (ms) durante el período de medición la vCPU estuvo en estado de espera. Dado que IDLE está incluido en este contador, los valores altos de Espera tampoco indican un problema. Pero si Wait IDLE es bajo cuando es alto, entonces la VM estaba esperando la finalización de las operaciones de E/S y esto, a su vez, puede indicar un problema con el rendimiento del disco duro o cualquier dispositivo virtual de la VM.
máx. limitado – cuánto tiempo (ms) durante el período de medición la vCPU estuvo en estado Listo debido al límite de recursos establecido. Si el rendimiento es inexplicablemente bajo, es útil comprobar el valor de este contador y el límite de CPU en la configuración de la máquina virtual. De hecho, las máquinas virtuales pueden tener límites que usted no conoce. Por ejemplo, esto sucede cuando una máquina virtual se clonó a partir de una plantilla que tenía un límite de CPU establecido.
cambiar esperar – cuánto tiempo durante el período de medición la vCPU esperó una operación con VMkernel Swap. Si el valor de este contador está por encima de cero, la máquina virtual definitivamente tiene problemas de rendimiento. Hablaremos más sobre SWAP en el artículo sobre contadores de RAM.
ESXTOP
Si los contadores de rendimiento en vCenter son buenos para analizar datos históricos, es mejor realizar un análisis en línea del problema en ESXTOP. Aquí todos los valores se presentan en forma completa (no es necesario traducir nada) y el período mínimo de medición es de 2 segundos.
La pantalla ESXTOP en la CPU se abre con la tecla "c" y se ve así:
Para mayor comodidad, puede dejar solo los procesos de la máquina virtual presionando Shift-V.
Para ver las métricas de los núcleos de máquinas virtuales individuales, presione "e" y escriba el GID de la máquina virtual que le interesa (30919 en la siguiente captura de pantalla):
Revisaré brevemente las columnas que se presentan de forma predeterminada. Se pueden agregar columnas adicionales presionando "f".
NWLD (Número de mundos) es el número de procesos en el grupo. Para expandir el grupo y ver las métricas de cada proceso (por ejemplo, para cada núcleo de una máquina virtual multinúcleo), presione "e". Si hay más de un proceso en un grupo, las métricas del grupo son iguales a la suma de las métricas de los procesos individuales.
%USADO – cuántos ciclos de CPU del servidor está utilizando un proceso o grupo de procesos.
%CORRER – cuánto tiempo durante el período de medición el proceso estuvo en el estado RUN, es decir hizo un trabajo útil. Se diferencia de %USED en que no tiene en cuenta el hiperprocesamiento, el escalado de frecuencia ni el tiempo dedicado a las tareas del sistema (%SYS).
%SYS - tiempo dedicado a tareas del sistema, por ejemplo: procesamiento de interrupciones, E/S, redes, etc. El valor puede ser alto si la máquina virtual tiene muchas E/S.
%OVRLP - cuánto tiempo pasó el núcleo físico en el que se ejecuta el proceso de VM en tareas de otros procesos.
Estas métricas se relacionan entre sí de la siguiente manera:
%USADO = %EJECUTAR + %SYS - %OVRLP.
Por lo general, la métrica %USED es más informativa.
%ESPERAR – cuánto tiempo durante el período de medición el proceso estuvo en el estado de espera. Incluye INACTIVO.
%INACTIVO – cuánto tiempo durante el período de medición el proceso estuvo en el estado INACTIVO.
% SWPWT – cuánto tiempo durante el período de medición la vCPU esperó una operación con VMkernel Swap.
%VMESPERAR – cuánto tiempo durante el período de medición la vCPU estuvo en estado de espera de un evento (generalmente E/S). No hay un contador similar en vCenter. Los valores altos indican problemas con E/S en la VM.
%ESPERAR = %VMWAIT + %IDLE + %SWPWT.
Si la VM no usa VMkernel Swap, al analizar los problemas de rendimiento, es recomendable mirar %VMWAIT, ya que esta métrica no tiene en cuenta el tiempo en que la VM no hizo nada (%IDLE).
%RDY – cuánto tiempo durante el período de medición el proceso estuvo en el estado Listo.
%CSTP – cuánto tiempo durante el período de medición el proceso estuvo en estado de parada.
%MLMTD – cuánto tiempo durante el período de medición la vCPU estuvo en estado Listo debido al límite de recursos establecido.
%WAIT + %RDY + %CSTP + %RUN = 100 %: el núcleo de la máquina virtual siempre se encuentra en uno de estos cuatro estados.
CPU en hipervisor
vCenter también tiene contadores de rendimiento de CPU para el hipervisor, pero no son nada interesantes: es solo la suma de los contadores de todas las máquinas virtuales en el servidor.
La forma más conveniente de ver el estado de la CPU en el servidor es en la pestaña Resumen:
Para el servidor, así como para la máquina virtual, existe una Alarma estándar:
Cuando la carga en la CPU del servidor es alta, las máquinas virtuales que se ejecutan en él comienzan a experimentar problemas de rendimiento.
En ESXTOP, los datos de carga de la CPU del servidor se presentan en la parte superior de la pantalla. Además de la carga de CPU estándar, que no es muy informativa para los hipervisores, hay tres métricas más:
UTILIDAD PRINCIPAL (%) – carga del núcleo del servidor físico. Este contador muestra cuánto tiempo ha estado trabajando el núcleo durante el período de medición.
UTIL PCPU(%) – si Hyper-Threading está habilitado, entonces hay dos subprocesos (PCPU) por núcleo físico. Esta métrica muestra cuánto tiempo ha estado funcionando cada subproceso.
UPC UTILIZADA(%) - lo mismo que PCPU UTIL(%), pero tiene en cuenta el escalado de frecuencia (ya sea reduciendo la frecuencia central para ahorrar energía o aumentando la frecuencia central debido a la tecnología Turbo Boost) y el hiperprocesamiento.
PCPU_USED% = PCPU_UTIL% * reloj de núcleo efectivo/reloj de núcleo nominal.
En esta captura de pantalla, para algunos núcleos, debido a Turbo Boost, el valor UTILIZADO es superior al 100%, ya que la frecuencia del núcleo es superior a la nominal.
Algunas palabras sobre cómo se tiene en cuenta el hiperprocesamiento. Si los procesos se ejecutan el 100 % del tiempo en ambos subprocesos del núcleo físico del servidor, mientras que el núcleo se ejecuta a la frecuencia nominal, entonces:
- CORE UTIL para core será 100%,
- PCPU UTIL para ambos hilos será 100%,
- El PCPU UTILIZADO para ambos subprocesos será del 50 %.
Si ambos subprocesos no funcionaron el 100 % del tiempo durante el período de medición, durante los períodos en que los subprocesos trabajaron en paralelo, la PCPU UTILIZADA para los núcleos se reduce a la mitad.
ESXTOP también tiene una pantalla con opciones de energía de la CPU del servidor. Aquí puede ver si el servidor utiliza tecnologías de ahorro de energía: estados C y estados P. Llamado por la tecla "p":
Problemas comunes de rendimiento de la CPU
Finalmente, repasaré las causas típicas de los problemas con el rendimiento de la CPU de la VM y daré breves consejos para resolverlos:
No hay suficiente reloj central. Si no es posible actualizar la VM a núcleos más potentes, puede intentar cambiar la configuración de energía para que Turbo Boost funcione de manera más eficiente.
Tamaño de máquina virtual incorrecto (demasiados/pocos núcleos). Si coloca pocos núcleos, habrá una gran carga en la CPU de la VM. Si es mucho, tome una parada conjunta alta.
Gran sobresuscripción de CPU en el servidor. Si la máquina virtual tiene un nivel alto de Listo, reduzca la sobresuscripción de CPU.
Topología NUMA incorrecta en máquinas virtuales grandes. La topología NUMA vista por la VM (vNUMA) debe coincidir con la topología NUMA del servidor (pNUMA). Sobre el diagnóstico y las posibles soluciones a este problema está escrito, por ejemplo, en el libro . Si no desea profundizar y no tiene restricciones de licencia en el sistema operativo instalado en la VM, cree muchos sockets virtuales en la VM para un núcleo. No perderás mucho 🙂
Eso es todo sobre la CPU para mí. Hacer preguntas. En la siguiente parte hablaré sobre la memoria RAM.
Enlaces de interés
Fuente: habr.com