CPU Co-Stop: qué mide %CSTP y cómo revisar las vCPU

El CPU Co-Stop es tiempo durante el que el planificador de ESXi detiene deliberadamente el avance de una vCPU para limitar su desfase respecto a otras vCPU de la misma máquina virtual. En esxtop aparece como %CSTP y tiene sentido en máquinas con varios procesadores virtuales. Es una señal de coordinación de ejecución: si crece de forma sostenida y coincide con una aplicación lenta, merece investigación.

Puede resultar desconcertante encontrarlo en una máquina a la que se le asignaron más vCPU para que fuera más rápida. El número configurado describe los procesadores que verá el sistema invitado, pero no demuestra que la aplicación los aproveche ni que el host los atienda sin esperas. Co-Stop ayuda a revisar esa decisión con datos, sin convertir cualquier porcentaje distinto de cero en una orden de recortar recursos.

-InfraCrew dice: Añadir vCPU sin medir se parece mucho a contratar más gente para una reunión que ya duraba demasiado.-

Coordinar el avance no exige arrancar todo a la vez

Las vCPU de una máquina multiprocesador necesitan mantener un avance suficientemente coordinado. Si una se adelanta demasiado respecto a otra, el planificador puede frenarla mientras la rezagada progresa. El objetivo es acotar ese desfase; el nombre del contador describe un mecanismo de planificación y no un fallo físico del procesador.

Conviene evitar una explicación heredada: afirmar que ESXi siempre necesita tener todos los núcleos físicos libres simultáneamente para ejecutar una VM con varias vCPU. VMware documenta la planificación conjunta relajada, que permite decisiones individuales y no impone esa condición general. Una VM con ocho vCPU no permanece necesariamente inmóvil hasta encontrar ocho procesadores disponibles al mismo tiempo.

Ese matiz cambia el diagnóstico. Una máquina grande puede funcionar bien si la carga aprovecha sus recursos y la plataforma está dimensionada para ella. El problema no se deduce de la ficha de configuración: se investiga observando qué ocurre durante el trabajo real, qué vCPU están ocupadas y cuándo aparecen las esperas.

Qué cuenta CSTP y qué preguntas deja abiertas

CPU Ready y Co-Stop no son intercambiables. Ready describe espera de una entidad que está preparada para ejecutar y aún no obtiene CPU; Co-Stop identifica la detención relacionada con la coordinación entre vCPU. Mirarlos juntos ayuda a separar síntomas, pero ninguno sustituye al tiempo de respuesta de la aplicación ni explica por sí solo toda la contención del host.

En esxtop, la vista de CPU permite revisar %CSTP junto a otros campos. Antes de interpretar el número hay que identificar la fila: una agrupación de VM no es lo mismo que una vCPU individual. No compares un agregado con un contador por procesador como si tuvieran idéntico significado; conserva la herramienta, el nivel de detalle y el intervalo de muestreo en las evidencias.

Tampoco existe un umbral universal que permita diagnosticar cualquier aplicación sin contexto. Un promedio largo puede esconder intervalos problemáticos y una muestra aislada puede coincidir con un evento puntual. La pregunta útil es si el comportamiento se repite, cuánto dura y qué impacto aparece a la vez en las operaciones que importan al usuario.

-InfraCrew dice: Un contador sin su intervalo y su fila es una cifra con muy buena presentación y pocas explicaciones.-

Por ejemplo, imagina una VM de dieciséis vCPU que procesa un cierre nocturno. Antes de cambiarla, registra cuándo empieza el retraso, su paralelismo efectivo y la carga de otras máquinas del host. Si el síntoma solo aparece durante esa ventana, una captura tomada por la mañana no sirve para absolver la configuración ni para culparla.

Una revisión de capacidad que permita comparar

La primera tarea es construir una línea de base: configuración de vCPU, comportamiento de la aplicación, esperas observadas y contexto del host durante una carga representativa. Añade al parte los cambios y trabajos que coincidan con la degradación. Sin ese punto de comparación, cualquier mejora posterior puede deberse simplemente a que ese día entraron menos peticiones.

Si hay indicios de sobredimensionamiento, plantea una prueba controlada de reducción conforme a los requisitos del sistema operativo y de la aplicación. Define antes qué resultado aceptarás, cómo volverás a la configuración anterior y qué ventana necesitas para hacerlo. Reducir de dieciséis a ocho vCPU puede ser una hipótesis para un caso concreto, no una receta aplicable a todos los servidores.

Tras el cambio, compara una carga equivalente y comprueba rendimiento funcional además de %CSTP. Si baja el contador pero el proceso de negocio tarda más, no has demostrado una mejora. Si la aplicación pierde capacidad de procesamiento paralelo, tendrás que reconsiderar la prueba aunque el gráfico del hipervisor parezca más tranquilo.

También puede ser necesario revisar capacidad y reparto del host, en lugar de modificar únicamente la VM afectada. Correlaciona las máquinas que comparten la ventana de trabajo y evita cambiar varios factores a la vez. El resultado que interesa es una explicación reproducible de la lentitud y una configuración que la carga pueda sostener, no conseguir una pantalla llena de ceros.

-InfraCrew dice: Si mejora el contador y empeora el cierre, el contador no va a dar la cara delante de contabilidad.-

Diccionario de la Crew

• vCPU: procesador virtual presentado al sistema operativo de una máquina virtual.
• Co-Stop: detención de ejecución relacionada con el desfase de avance entre vCPU de una VM multiprocesador.
• CPU Ready: espera para obtener CPU cuando la entidad ya está preparada para ejecutar.
• esxtop: herramienta de ESXi para observar recursos y contadores de rendimiento.
• Planificación conjunta relajada: mecanismo de coordinación que limita el desfase entre vCPU sin exigir que todas se ejecuten siempre simultáneamente.