¿Qué es CPU Ready en VMware?
CPU Ready explica por qué una máquina virtual puede esperar CPU aunque su utilización parezca baja. Así se interpreta el contador, se normalizan sus valores y se investiga sin añadir vCPU a ciegas.
Una máquina virtual puede responder con lentitud mientras su sistema operativo muestra una CPU bastante tranquila. CPU Ready mide el tiempo que una CPU virtual está preparada para ejecutar trabajo, pero espera a que ESXi le dé acceso a CPU física. Es una pista sobre planificación, no el porcentaje de procesador que está consumiendo una aplicación.
La diferencia importa cuando alguien propone añadir procesadores virtuales para arreglar cualquier retraso. Si el problema está en conseguir turno, ampliar la VM puede complicar el diagnóstico en lugar de resolverlo. Antes de cambiar su tamaño conviene distinguir cuánto trabajo tiene, cuánto consigue ejecutar y cuánto tiempo pasa esperando.
La aplicación tiene trabajo; el procesador aún no tiene turno
Cada vCPU es un procesador virtual que ESXi debe planificar sobre los recursos físicos del host. Una vCPU puede estar ejecutándose, no necesitar CPU o estar lista y esperando. Ready corresponde a esa última situación, que el sistema invitado no interpreta necesariamente como un procesador ocupado al cien por cien.
Pensemos en una aplicación de inventario cuyo proceso necesita unos instantes de CPU para responder a una consulta. Si comparte host con otras cargas que demandan ejecución, puede esperar antes de avanzar. Desde fuera vemos una respuesta más lenta; desde dentro podemos seguir viendo utilización moderada. Es un ejemplo ilustrativo, no una prueba de que toda latencia de una VM proceda de Ready.
-InfraCrew dice: La aplicación ha llegado puntual. El turno de CPU todavía está buscando aparcamiento.-
Tampoco hay que confundir Ready con esperar una lectura de disco. En esxtop, los estados de espera y de ejecución tienen contadores distintos. Revisar almacenamiento, memoria y comportamiento de la aplicación sigue siendo necesario: una métrica de CPU no convierte automáticamente el resto de la infraestructura en inocente.
Milisegundos sin intervalo cuentan media historia
En los gráficos de rendimiento puede aparecer tiempo Ready acumulado en milisegundos; esxtop ofrece %RDY. Una cantidad acumulada necesita el intervalo de muestreo para tener significado. Comparar directamente un punto de veinte segundos con otro de cinco minutos puede hacer que una situación idéntica parezca un empeoramiento enorme.
Como ejemplo propio, supongamos que una vCPU acumula 800 milisegundos Ready durante una muestra de veinte segundos. La cuenta es 800 dividido entre 20.000, multiplicado por cien: un 4 % de ese intervalo. Los mismos 800 milisegundos repartidos en cinco minutos representarían aproximadamente un 0,27 %. El número bruto es igual; la espera relativa no lo es.
Hay otra comprobación imprescindible: saber si el dato pertenece a una vCPU o suma varias. Si esos 800 milisegundos fueran el agregado de cuatro vCPU, dividir también entre cuatro daría una media del 1 % por vCPU en veinte segundos. Esa media ayuda a comparar tamaños, pero puede ocultar que una de ellas soporta más espera que las demás.
Anota contador, instancia, unidad e intervalo antes de sacar conclusiones. Conserva esos datos junto a la medición: una captura sin contexto resulta difícil de comparar después. No dividas otra vez por el número de vCPU si la herramienta ya entrega un valor individual o normalizado.
Qué revisar cuando la espera coincide con la lentitud
La presión de otras cargas sobre el host es una posibilidad, pero Ready también puede incluir espera causada por un límite de CPU configurado. En esxtop, %MLMTD ayuda a identificar esa restricción. Por eso conviene revisar límites y asignaciones antes de atribuir el problema únicamente a falta de hardware.
El tamaño de la VM merece una revisión basada en demanda real. Más vCPU solo aportan capacidad útil si la carga puede aprovecharlas; el dimensionamiento también afecta a la planificación y a la topología. No existe una proporción universal entre vCPU y núcleos físicos que sirva igual para todas las aplicaciones.
-InfraCrew dice: Ocho vCPU «por si acaso» también merecen una línea en el inventario de decisiones pendientes.-
Una investigación razonable empieza alineando las horas de la queja, la latencia de la aplicación y los contadores del host. Después puede comparar periodos equivalentes y estudiar las vCPU por separado. El objetivo es encontrar una relación repetible, no perseguir el pico más llamativo de toda la semana.
Cambiar una cosa y comprobar el servicio
Supongamos que la lentitud aparece durante un proceso por lotes vecino y desaparece fuera de esa ventana. Una prueba controlada podría redistribuir la carga, revisar el límite identificado o ajustar el tamaño de la VM. La decisión depende de la evidencia y de las condiciones operativas, con una ventana y una forma de volver atrás cuando proceda.
Tras el cambio, compara el mismo tipo de carga y mide la experiencia del servicio. Si baja Ready pero la consulta sigue tardando lo mismo, queda trabajo de diagnóstico. Un umbral aislado tampoco demuestra una incidencia: importan duración, distribución, exigencia de latencia y síntomas observados.
-InfraCrew dice: El gráfico puede ponerse verde antes que el usuario. Conviene preguntar a los dos.-
Diccionario de la Crew
vCPU — Procesador virtual presentado a una máquina virtual y planificado por el hipervisor sobre recursos físicos.
