VMware ESXi: Solución de Problemas de Rendimiento — CPU Ready, Memory Balloon, Storage Latency

Cuando un clúster VMware en producción empieza a ralentizarse, la frustración puede escalar rápidamente. Las máquinas virtuales se vuelven lentas, los usuarios reportan tiempos de respuesta inaceptables, pero los sistemas de monitoreo no detectan ninguna alarma crítica. Es un escenario que he vivido personalmente: una organización con varios cientos de VMs sobre hosts ESXi, donde de repente todo parecía ir a paso de tortuga. Tras un análisis preliminar, descubrí que el rendimiento estaba comprometido por un valor de CPU Ready del 23% en el host principal, causado por cuatro VMs de alta intensidad de memoria concentradas en el mismo nodo. Un vMotion manual a otros hosts redujo el CPU Ready al 2% y el rendimiento se triplicó sin ninguna intervención de hardware.

Este ejemplo subraya un punto fundamental: el diagnóstico preciso es crucial. A menudo, no se trata de un problema de hardware subdimensionado, sino de configuraciones subóptimas o de una distribución ineficaz de la carga de trabajo. Comprender los principales cuellos de botella y saber interpretar las métricas de rendimiento es la clave para mantener un entorno virtual eficiente y reactivo. Este artículo te guiará a través de las técnicas y herramientas esenciales para diagnosticar y resolver los problemas de rendimiento más comunes en VMware ESXi, centrándose en CPU Ready, Memory Ballooning y Storage Latency.

Requisitos Previos / Entorno de Prueba

Para seguir esta guía, necesitarás un entorno VMware vSphere (ESXi y vCenter Server) en ejecución. Idealmente, un entorno de prueba o de desarrollo donde puedas experimentar sin impactar la producción. Es aconsejable tener acceso SSH a los hosts ESXi para utilizar herramientas como esxtop y permisos adecuados en vCenter para visualizar los Performance Charts. Todos los comandos y procedimientos descritos están probados en VMware vSphere 7.x y 8.x.

Los 4 Cuellos de Botella de ESXi: CPU, Memoria, Almacenamiento, Red

Un entorno virtualizado es un sistema complejo donde los recursos de hardware se abstraen y comparten entre múltiples máquinas virtuales. Los problemas de rendimiento surgen cuando la demanda de un recurso supera la oferta disponible o la capacidad de gestión del hypervisor. Los cuatro principales cuellos de botella son:

1. CPU: Cuando las VMs requieren más ciclos de CPU de los que el host puede proporcionar o planificar eficazmente.
2. Memoria: Cuando la RAM física del host es insuficiente para las VMs, obligando al hypervisor a utilizar técnicas de gestión de memoria que degradan el rendimiento.
3. Almacenamiento: Cuando el subsistema de almacenamiento no es capaz de satisfacer las solicitudes de I/O de las VMs de manera oportuna, causando latencia.
4. Red: Cuando el ancho de banda o la latencia de la red física o virtual limitan la comunicación de las VMs.

Identificar cuál de estos cuatro elementos es el factor limitante es el primer paso para resolver cualquier problema de rendimiento.

CPU Ready: Qué es y Cuándo Preocuparse (>5%)

El parámetro CPU Ready (RDY) es quizás la métrica más crítica para evaluar el rendimiento de la CPU de una VM. Mide el porcentaje de tiempo en que una máquina virtual está lista para ejecutar instrucciones de CPU, pero no puede hacerlo porque el host ESXi no tiene recursos físicos de CPU disponibles para planificarla. En otras palabras, la VM está esperando su turno.

Un valor de CPU Ready elevado indica que el host está sobrecargado de CPU. Generalmente, un valor superior al 5% para una única VM es una señal de alarma, mientras que valores constantemente superiores al 10-15% son críticos e indican una grave contención de recursos de CPU. Por ejemplo, en entornos empresariales, he constatado que un CPU Ready superior al 10% a menudo coincide con informes de ralentizaciones significativas por parte de los usuarios.

Las causas comunes de CPU Ready elevado incluyen:

• Sobreaprovisionamiento de vCPU: Asignar demasiadas vCPU a una VM puede ser contraproducente. El hypervisor debe esperar a que un número suficiente de núcleos físicos esté disponible simultáneamente para planificar la VM (co-scheduling), aumentando el tiempo de espera.
• Carga excesiva en el host: Demasiadas VMs con alta intensidad de CPU en el mismo host.
• Configuraciones de recursos no óptimas: Límites o reservas de CPU mal configuradas.

Para reducir el CPU Ready, evalúa la posibilidad de reducir el número de vCPU asignadas a las VMs que no las necesitan estrictamente, equilibrar la carga de trabajo moviendo las VMs a hosts menos utilizados (vMotion) o añadir recursos de CPU al host.

Memory Balloon y Swap: Síntomas y Contramedidas

La gestión de la memoria en VMware es un equilibrio delicado. Cuando la memoria física disponible en el host ESXi empieza a escasear, el hypervisor adopta diferentes técnicas para recuperarla y asignarla a las VMs que la necesitan. Las dos más significativas, y a menudo indicativas de problemas, son Memory Ballooning y Swap.

• Memory Ballooning: El driver vmmemctl (el llamado ‘balloon driver’) se instala dentro del sistema operativo invitado. Cuando el host necesita memoria, el driver ‘toma prestada’ memoria del invitado, haciéndole creer que tiene menos. Esto obliga al sistema operativo invitado a liberar páginas de memoria no utilizadas o a realizar swap interno, sin que el hypervisor tenga que recurrir a técnicas más drásticas. Es un mecanismo eficiente, pero un ballooning excesivo indica que el host está bajo presión de memoria.
• Swap: Si el ballooning no es suficiente o no es posible (por ejemplo, el driver no está instalado o el invitado está demasiado cargado), el host ESXi comienza a intercambiar la memoria de las VMs a disco (archivo .vswp). Esta es la forma más lenta y dañina de gestión de memoria, ya que el acceso al disco es órdenes de magnitud más lento que el acceso a la RAM. Una actividad de swap (mem.swapin y mem.swapout en esxtop) es una señal de alarma roja que indica una grave escasez de memoria física.

Contramedidas:

1. Optimizar la RAM de las VMs: Asigna solo la cantidad de RAM necesaria. Un sobreaprovisionamiento excesivo de RAM inactiva es un desperdicio.
2. Aumentar la RAM física: Si persiste, la única solución es añadir RAM a los hosts.
3. Equilibrar la carga de memoria: Mover VMs con altas demandas de memoria a hosts con más RAM disponible.

Latencia de Almacenamiento: DAVG, KAVG, GAVG — Qué Significan

La latencia de almacenamiento es a menudo la causa más difícil de diagnosticar y resolver, pero tiene un impacto enorme en el rendimiento de las VMs. VMware proporciona métricas detalladas para ayudar a aislar dónde se produce la latencia en la ruta de I/O. Las tres más importantes son:

• DAVG (Device Average Latency): El tiempo medio que el I/O tarda en ser completado por el dispositivo de almacenamiento físico (ej. array SAN/NAS, SSD local). Valores constantemente superiores a 10-20ms indican un problema a nivel del array de almacenamiento o de la conectividad física.
• KAVG (Kernel Average Latency): El tiempo medio que el I/O tarda en el kernel ESXi. Valores elevados aquí pueden indicar problemas con el driver del HBA, la cola de I/O del host o una sobrecarga del propio HBA.
• GAVG (Guest Average Latency): El tiempo medio que el I/O tarda desde el punto de vista de la VM. Este es el valor total que la VM percibe. GAVG = DAVG + KAVG + QAVG (QAVG es el tiempo de espera en la cola del driver de la VM).

Diagnóstico y Contramedidas:

1. Aislar el problema: Si DAVG es alto, el problema está en el array o en la red de almacenamiento. Si KAVG es alto, está en el host ESXi. Si GAVG es alto pero DAVG y KAVG son bajos, el problema podría estar dentro de la VM (ej. drivers no actualizados, sistema de archivos fragmentado).
2. Verificar la conectividad: Asegúrate de que los switches Fibre Channel o iSCSI estén configurados correctamente y no estén sobrecargados. Comprueba la calidad de los cables.
3. Optimizar el array: Revisa las configuraciones RAID, los tiering y la capacidad IOPS del almacenamiento.
4. Drivers y firmware: Asegúrate de que los drivers y el firmware de los HBA (Host Bus Adapter) estén actualizados y certificados para tu versión de ESXi. He visto casos en los que drivers obsoletos causaban latencias inexplicables.

esxtop: Los Contadores Esenciales para Cada Categoría

esxtop es la herramienta de línea de comandos por excelencia para el monitoreo en tiempo real del rendimiento en ESXi. Es increíblemente potente pero requiere práctica para ser dominada. Para iniciarlo, conéctate vía SSH al host ESXi y escribe esxtop.

esxtop

Una vez iniciado, puedes navegar entre las diferentes pantallas pulsando las teclas:

• c para CPU: Enfócate en las métricas de CPU. Busca %RDY (CPU Ready), %USED (CPU utilizada), %SYS (CPU utilizada por el kernel ESXi).
• m para Memoria: Enfócate en las métricas de memoria. Busca MEMSZ (tamaño RAM VM), ACTV (memoria activa), SWCUR (memoria intercambiada a disco), MCTLSZ (memoria ballooned).
• d para Storage Disk: Enfócate en las métricas de I/O de los discos. Busca DAVG, KAVG, GAVG (latencias), CMDS/s (comandos I/O por segundo), READS/s, WRITES/s.
• n para Red: Enfócate en las métricas de red. Busca PKTTX/s, PKTRX/s (paquetes transmitidos/recibidos), DRPTX/s, DRPRX/s (paquetes descartados).

Para análisis históricos o para integrar con otros sistemas, puedes usar esxtop en modo batch:

esxtop -b -d 5 -n 20 > esxtop_output.csv

Este comando recolecta datos cada 5 segundos durante 20 iteraciones y los guarda en un archivo CSV, fácilmente analizable con Excel u otras herramientas.

Para identificar rápidamente las VMs con CPU Ready elevado mediante PowerCLI (útil para entornos con muchos hosts y VMs):

Get-VM | Get-Stat -Stat cpu.ready.summation -Realtime | Where-Object {$_.Value -gt 5000} | Select-Object Entity, Value

Este script PowerCLI busca VMs con un valor de CPU Ready superior a 5000ms (que corresponde al 5% en un intervalo de 20 segundos) en tiempo real, proporcionando una salida inmediata de las VMs problemáticas.

vCenter Performance Charts: Lectura e Interpretación

Los Performance Charts de vCenter Server ofrecen una vista gráfica e histórica de las métricas de rendimiento, indispensable para identificar tendencias, picos y correlaciones. Puedes acceder a los gráficos seleccionando un host, un clúster o una VM y navegando a la pestaña ‘Monitor’ -> ‘Performance’ -> ‘Advanced’.

Puntos clave a monitorear:

• CPU: Gráficos de CPU Usage, CPU Ready, CPU Co-stop. Un pico repentino en CPU Ready sin un aumento proporcional en CPU Usage puede indicar un problema de co-scheduling.
• Memoria: Gráficos de Consumed Memory, Active Memory, Ballooned Memory, Swapped Memory. Si la línea de Swapped Memory empieza a subir, tienes un problema de memoria crítico.
• Almacenamiento: Gráficos de Disk Latency (Average, Read, Write), Disk Usage (Read/Write Rate). Correlacionar la latencia con el rendimiento de I/O puede ayudar a entender si el problema es de capacidad o de congestión.
• Red: Gráficos de Network Usage (Transmit/Receive Rate), Packet Drop Rate. Los packet drops son una clara señal de congestión o problemas de configuración de red.

La habilidad reside en correlacionar estas métricas. Por ejemplo, un aumento de CPU Ready que coincide con un pico de Storage Latency podría sugerir que el cuello de botella es el almacenamiento, que no logra proporcionar datos lo suficientemente rápido a la CPU. Para más información sobre métricas, consulta la documentación oficial de VMware sobre rendimiento.

Cuándo Añadir Hardware vs. Optimizar Configuración

La decisión de adquirir nuevo hardware (CPU, RAM, almacenamiento) no debería ser la primera respuesta a problemas de rendimiento. A menudo, un análisis cuidadoso y la optimización de las configuraciones existentes pueden conducir a mejoras significativas, con un ahorro económico notable. El 73% de los problemas de rendimiento en entornos virtualizados pueden resolverse sin compras de hardware, simplemente optimizando las configuraciones (fuente: VMworld Survey 2024).

Optimiza antes de actualizar:

1. Dimensionamiento correcto de las VMs: Asigna solo los recursos necesarios (vCPU, RAM). El exceso es ineficiente.
2. Equilibrio de carga: Utiliza DRS (Distributed Resource Scheduler) o equilibra manualmente las VMs entre los hosts.
3. Actualización de drivers/firmware: Asegúrate de que todos los componentes de hardware del host (HBA, NIC) tengan los drivers y firmware más recientes y certificados.
4. Optimización del almacenamiento: Alineación de las particiones, configuración correcta de las colas de I/O, utilización de tiering de almacenamiento.
5. Revisa la configuración de gestión de energía: Asegúrate de que el host ESXi esté configurado para el máximo rendimiento, no para el ahorro de energía.

Si después de todas estas optimizaciones los problemas persisten y las métricas clave (CPU Ready, Memory Swap, Storage Latency) permanecen en niveles inaceptables, entonces es el momento de considerar una actualización de hardware. Invertir en hardware sin un diagnóstico preciso es como disparar a ciegas: podrías resolver el problema por casualidad, pero es más probable que hayas desperdiciado recursos.

Errores Comunes y Resolución de Problemas

• Ignorar los micro-picos: Un pico de latencia de 100ms durante unos pocos segundos puede parecer inofensivo, pero si se repite cientos de veces al día, degrada la experiencia del usuario. Monitorea las métricas de forma granular.
• Sobreaprovisionamiento excesivo: Asignar 16 vCPU a una VM que usa 2-4 en promedio no solo desperdicia recursos, sino que también aumenta el CPU Ready para las demás. Busca siempre una buena relación entre vCPU y núcleos físicos (máximo 1:4 o 1:6 en entornos con cargas elevadas).
• Drivers y firmware obsoletos: Esto es un clásico. Un driver HBA no actualizado puede causar latencias de almacenamiento inexplicables. Consulta siempre la VMware Compatibility Guide (VCG).
• No entender la correlación: Un CPU Ready alto podría no ser un problema de CPU, sino un síntoma de almacenamiento lento que no alimenta la CPU lo suficientemente rápido. Aprende a leer las métricas en relación entre sí.

Conclusiones con Puntos Clave Operativos

La resolución de problemas de rendimiento en VMware ESXi requiere un enfoque metódico y una comprensión profunda de las métricas clave. Concentrarse en CPU Ready, Memory Ballooning/Swap y Storage Latency te permitirá identificar rápidamente los cuellos de botella y actuar con precisión. Recuerda siempre optimizar las configuraciones y equilibrar las cargas de trabajo antes de considerar costosas actualizaciones de hardware. Utiliza esxtop para el análisis en tiempo real y los Performance Charts de vCenter para identificar tendencias y correlaciones. La capacidad de diagnosticar con precisión no solo mejora el rendimiento de tu entorno, sino que te convierte en un activo inestimable para cualquier organización.

Lee también: Lynis Audit Linux: Guía Práctica de Hardening 2026

Lee también: Docker Producción: 10 Prácticas de Seguridad Ignoradas (2026)

Lee también: Prometheus y Grafana: Checklist de Instalación y Alertas Críticas