Sobrecompromiso de CPU: cómo ralentiza los servidores virtuales

Sobrecarga de la CPU ralentiza los servidores virtuales porque el hipervisor asigna más vCPUs que núcleos físicos hay, lo que provoca tiempos de espera. Muestro las causas, valores medidos reales como el CPU Ready Time y ajustes específicos que utilizo para mantener estable el rendimiento del VPS.

Puntos centrales

Antes de profundizar, clasificaré los aspectos más importantes y delinearé los típicos malentendidos. Muchos operadores confunden alta utilización con eficiencia, aunque las colas determinan los tiempos de respuesta. Los detalles del programador determinan si las aplicaciones funcionan sin problemas o se estancan. Resumo los temas centrales que desarrollaré en los capítulos siguientes. La lista sirve de referencia compacta para tomar decisiones rápidas.

• programador y time slicing determinan cómo se asignan las vCPUs.
• CPU lista muestra los tiempos de espera y avisa con antelación de los cuellos de botella.
• Invitados SMP (múltiples vCPUs) aumentan la sobrecarga y la latencia.
• Rightsising y la supervisión mantienen los picos de carga manejables.
• Selección de proveedores sin overbooking garantiza un rendimiento constante.

¿Qué significa técnicamente sobrecompromiso de CPU?

Overcommit Esto significa que asigno más núcleos virtuales de los que tiene físicamente el host y confío en el planificador del hipervisor. KVM o VMware asignan el tiempo de computación a través de time slicing, que es discreto bajo carga baja y parece permitir una alta densidad. Bajo carga paralela, sin embargo, los tiempos de espera aumentan porque varias vCPUs requieren tiempo de computación al mismo tiempo y el programador tiene que programarlas una tras otra. Red Hat advierte que las máquinas virtuales SMP en particular con muchas vCPUs pierden mucho rendimiento tan pronto como la suma de las vCPUs excede significativamente los núcleos físicos [1]. Los expertos de VMware cuantifican esto a través del Tiempo de Preparación de la CPU: 1000 ms de tiempo de espera por vCPU corresponde a alrededor de 5% de pérdida de rendimiento, acumulativamente por núcleo [3].

Por qué se ralentizan los servidores virtuales

Colas son la razón principal por la que los servidores virtuales se ralentizan cuando están sobrecargados, aunque la utilización de la CPU parezca alta. Una vCPU sólo puede ejecutarse cuando un núcleo físico está libre; hasta entonces, la CPU lista aumenta y la aplicación espera. Con varias máquinas virtuales con picos paralelos, el efecto se agrava porque todas están „listas para ejecutarse“ y el programador sólo puede trabajar en franjas de tiempo. En particular, las cargas de trabajo de latencia crítica, como bases de datos, API o backends de tienda, reaccionan de forma sensible, ya que cada cambio de contexto adicional y cada retraso desencadenan efectos en cadena. Entonces observo tiempos de espera, tiempos de respuesta inestables y una varianza creciente que irrita notablemente a los usuarios.

Variables medidas: CPU Ready, Steal & Co.

Indicadores como CPU Ready, Co-Stop y Steal Time me muestran con antelación si el overcommitment está afectando a mi VM. CPU Ready en las métricas del hipervisor debería permanecer por debajo de 5% de media; si el valor sube a porcentajes de dos dígitos, el rendimiento cae notablemente [3]. Co-Stop indica que las máquinas virtuales SMP no pueden programarse simultáneamente, lo que ralentiza el multi-threading. En huéspedes Linux, leo Steal Time, que muestra cuánto tiempo le está quitando el host a mi VM; he explicado el trasfondo y la puesta a punto de forma accesible aquí: Tiempo de robo de CPU. Si se combinan estas tres señales, se pueden reconocer a tiempo los cuellos de botella y evitar que los problemas de latencia afecten a la aplicación.

Un ejemplo real: Cuando 5:1 rompe el límite

Práctica vence a la teoría en cuanto se mezclan cargas de trabajo reales: Un host con 4 núcleos físicos y 5 máquinas virtuales con 4 vCPUs cada una no parece problemático en reposo, pero muestra tiempos de espera masivos bajo carga. Si una VM inicia el procesamiento de imágenes o las copias de seguridad, el planificador da prioridad, pero las VM restantes acumulan valores de CPU lista de más de 2000 ms, lo que supone una pérdida de rendimiento de alrededor de 10% por núcleo [3]. En una prueba documentada de un servidor SQL, el rendimiento cayó de 25.200 transacciones por minuto a menos de la mitad [3] cuando se activó el funcionamiento en segundo plano. La E/S también se ralentiza indirectamente porque las vCPUs se adelantan durante los accesos a los dispositivos de bloque y los pipelines se atascan. Entonces experimento una mezcla de picos altos, colas largas y fluctuaciones inesperadas en los tiempos de respuesta.

Riesgos especiales para los huéspedes del SMP

SMP-VMs con muchas vCPUs requieren slots coordinados en varios núcleos físicos, lo que aumenta el esfuerzo de programación y los tiempos de espera. Cuantas más vCPUs tenga una única VM, más a menudo esperará a que se reúnan todas las franjas horarias requeridas. Por lo tanto, Red Hat aconseja favorecer varias VMs más pequeñas con pocas vCPUs en lugar de ejecutar huéspedes individuales de „ancho de banda“ [1]. Un ratio de sobrecompromiso de 10:1 se considera un valor máximo aproximado; considero que bastante menos es sensato en entornos productivos, especialmente para servicios con una carga pesada [1]. Si estableces la latencia como la máxima prioridad, limita las vCPUs por VM y optimiza los hilos para que puedan manejarse con menos carga base de núcleos.

Prácticas de alojamiento web: efectos en los sitios web

Sitios web en hosts sobrecargados reaccionan con tiempos de carga más largos, un tiempo hasta el primer byte inestable y unas vitales web básicas deficientes. Los motores de búsqueda desclasifican las páginas lentas, los visitantes rebotan más rápido y las cadenas de conversión se rompen en micro retardos discretos [2]. En los entornos compartidos, mucha gente está familiarizada con el „vecino ruidoso“; en los VPS con overcommitment, esto ocurre de forma más sutil porque nominalmente se asignan más vCPU. Por lo tanto, en caso de picos de tráfico, siempre compruebo primero si los valores de ready y steal son altos en lugar de ajustar a ciegas el servidor web. Si quieres reducir costes, deberías tener en cuenta los riesgos de alojamiento web ventajoso y exigir límites claros contra el exceso de reservas [2].

Sobrecompromiso frente a bare metal

Comparación muestra: El metal desnudo ofrece latencias predecibles y rendimiento lineal, mientras que la virtualización sobrecargada se vuelve inestable bajo carga. Para cargas de trabajo sensibles a la latencia, como bases de datos, colas, pilas de observabilidad y API en tiempo real, la dedicación se amortiza rápidamente. Yo prefiero núcleos dedicados o bare metal en cuanto la CPU Ready se hace notar o los huéspedes SMP se estancan. Si necesita flexibilidad, puede construir un puente con instancias de CPU reservadas o grupos de hosts sin sobrecompromiso. La comparación ofrece una visión estructurada de las opciones Alojamiento Bare Metal, que compara brevemente los puntos fuertes y los compromisos.

Dimensionamiento correcto: ¿cuántas vCPU tienen sentido?

Rightsising empieza con la demanda real: Mido la CPU, la cola de ejecución, el disco y Net-IO, así como los patrones de bloqueo-espera a lo largo de varios perfiles diarios. Si los valores medidos muestran un grupo de hilos máximo de cuatro, asigno inicialmente de dos a cuatro vCPU y sólo las aumento si Ready y Co-Stop siguen siendo discretos. La regla empírica „máximo 10 vCPUs por núcleo físico“ es un tope, no un valor objetivo; planifico de forma más conservadora para la producción [1]. Las máquinas virtuales grandes con muchas vCPU parecen atractivas, pero aumentan el esfuerzo de coordinación y las fluctuaciones de latencia. Escalo horizontalmente las máquinas virtuales pequeñas y limpias, y así mantengo las colas cortas y eficientes.

Supervisión y alertas: qué configuro

Monitoreo hace que el overcommitment sea visible antes de que los usuarios se den cuenta, por lo que establezco límites claros. CPU Ready en la media de 1 minuto debería permanecer idealmente por debajo de 5% por vCPU, Co-Stop debería tender permanentemente a cero y Steal Time sólo debería ser perceptible durante un breve espacio de tiempo [3]. Si esto se supera, escalo horizontalmente, aparco los trabajos en segundo plano lejos de las máquinas virtuales productivas o muevo a los huéspedes a hosts con aire. Separo las alertas según su gravedad: Alerta instantánea para aumentos bruscos, ticket para picos moderados recurrentes. De este modo, evito la fatiga de alertas e intervengo específicamente cuando la latencia se vuelve realmente crítica para el negocio.

Selección de proveedores: En qué me fijo

Selección de un proveedor de VPS determina la consistencia bajo carga, por lo que examino las ofertas de forma crítica en busca de overbooking. La información transparente sobre los ratios vCPU-core, las promesas claras sobre los núcleos dedicados y los benchmarks consistentes son obligatorios. En una comparación realizada en 2025, las ofertas con almacenamiento NVMe, una generación de CPU moderna y sin sobreventa de CPU obtuvieron los mejores resultados, con un tiempo de actividad estable y una latencia constante [6]. El precio por sí solo a menudo conduce a una sobreventa oculta, que resulta más cara que los recursos honestos en escenarios productivos. La siguiente tabla muestra parámetros básicos que yuxtapongo para evitar cuellos de botella.

Proveedor	vCPU	RAM	Memoria	Tiempo de actividad	Precio/mes	Ganador de la prueba
webhoster.de	4-32	8-128 GB	NVMe	99,99%	desde 1	Sí
Hetzner	2-16	4-64 GB	SSD	99,9%	desde 3	No
Contabo	4-24	8-96 GB	SSD	99,8%	a partir de 5	No

Planificación de la capacidad: en cuanto los picos de carga sean inminentes

Planificación Empiezo con los perfiles de carga de trabajo: Horas punta, duración de las ráfagas, paralelismo y presupuestos de latencia. Cuando aumenta la carga base, primero aumento verticalmente mientras el tiempo de preparación permanezca estable; si la curva se inclina, divido los servicios en varias máquinas virtuales más pequeñas. Separo sistemáticamente los trabajos en segundo plano del front-end para que los procesos de pedido o de pago no compitan con los informes. El autoescalado ayuda, pero sin límites superiores ni métricas claras, produce costosas desconexiones. Una lógica paso a paso funciona mejor: definir umbrales, probar medidas, medir resultados y luego afinar umbrales.

Qué es realmente una vCPU: SMT y efectos de frecuencia

vCPU suele significar un hilo de hardware (SMT/hyper-threading), no necesariamente un núcleo físico completo. Dos vCPU pueden ubicarse en un núcleo y compartir descodificadores, cachés y unidades de ejecución. Bajo carga pura de enteros o memoria, SMT aporta ventajas notables, pero con pipelines saturados, los hilos compiten directamente por los recursos. Esto explica por qué los hosts con „muchas vCPU“ no escalan linealmente bajo carga: Aunque el planificador puede distribuir slots, no puede crear más unidades físicas de computación. Las políticas de potencia y turbo también influyen. Si muchos subprocesos se ejecutan en paralelo, las frecuencias turbo disminuyen y el rendimiento de un solo subproceso cae. Para las clases de latencia, considero núcleos dedicados, SMT-Off o CPU pinning para dar a los hilos ventanas de rendimiento predecibles.

Conciencia NUMA: la localidad de la memoria decide

NUMA separa los hosts multisocket modernos en nodos con su propia conexión de memoria. Las grandes máquinas virtuales SMP que se extienden por varios nodos NUMA pagan con una mayor latencia de memoria, accesos remotos y coordinación adicional. Organizo la asignación de vCPU y RAM de modo que una máquina virtual quepa preferiblemente en un nodo. En términos prácticos, esto significa menos vCPUs por VM, pero escalado horizontal. En el huésped, evito los grupos de hilos sobredimensionados y sincronizados globalmente y confío en la fragmentación por instancia. Los que virtualizan bases de datos se benefician doblemente: mejor tasa de acierto de la caché y menos tráfico entre nodos. La desubicación NUMA a menudo se disfraza de „problemas de CPU“, pero se hace visible en el aumento de la latencia de la memoria y los errores de lectura, mientras que CPU Ready sólo tiene un efecto moderado.

Modelos de ráfagas y créditos: límites ocultos

Instancias de ráfaga con créditos de CPU ofrecen buenos valores en modo inactivo, pero se ralentizan cuando no hay créditos, aunque el CPU Ready sigue siendo discreto. Esto es delicado para los operadores porque los picos de latencia se producen „de la nada“. Por eso compruebo si una tarifa utiliza créditos o reglas de „reparto equitativo“ y si se garantiza un rendimiento mínimo. Las cargas de trabajo con picos periódicos (cron, ETL, lote de facturas) consumen rápidamente los créditos y luego caen en un frenazo brusco. La solución: cambiar a núcleos reservados o desacoplar las ráfagas, por ejemplo utilizando un perfil de lote independiente con su propia ventana de tiempo para que las API productivas no se topen con el estrangulamiento. El sobrecompromiso más el estrangulamiento del crédito es la combinación más desfavorable para unos tiempos de respuesta predecibles.

Contenedores en el VPS: evitar la doble programación

Orquestación de contenedores en una máquina virtual ya sobrecargada conduce fácilmente a un „doble sobrecompromiso“. El programador del host da prioridad a las máquinas virtuales y el programador del invitado a los contenedores, sin conocer la disponibilidad real de los núcleos. Por lo tanto, establezco cuotas de CPU claras y utilizo cpuset, para vincular contenedores críticos a vCPUs específicas. Al mismo tiempo, mantengo la suma de hilos de contenedor por debajo del presupuesto realista disponible de la máquina virtual, no por debajo del valor nominal de vCPU. Defino cuotas inferiores para los contenedores de compilación o por lotes para dar prioridad a los servicios frontales. Importante: irqbalance y la pila de red no deben saturar las vCPU críticas con inundaciones de interrupciones; en caso de duda, aíslo una o dos vCPU para las interrupciones de red y almacenamiento con el fin de amortiguar los picos de latencia.

Práctica de la medición: cómo leer los números correctos

En el hipervisor Compruebo CPU Ready (total y por vCPU), co-stop y longitud de cola de ejecución por host. En KVM, correlaciono domstats de las máquinas virtuales con la carga del host y la carga de IRQ. En el huésped Observo %steal, %iowait, cola de ejecución (r) y cambios de contexto. Un patrón recurrente es: cola de ejecución alta + aumento de %steal + latencia fluctuante = sobrecompromiso. Si %steal se mantiene bajo, pero los fallos L3 y las syscalls aumentan, tiendo a apuntar a problemas de retención de bloqueos o NUMA. También cuento los hilos de petición activos y los comparo con los recuentos de vCPU: si los pools web o de trabajadores superan permanentemente el presupuesto de núcleos, yo mismo creo colas. Es mejor limitar y rechazar las colas entrantes en lugar de procesarlas con retraso: esto mejora la percepción del usuario y estabiliza los sistemas.

Palancas de ajuste concretas en el huésped y el anfitrión

Beneficios rápidos Lo consigo con unos pocos pasos precisos: En la BIOS, configuro los perfiles de rendimiento, desactivo los estados C profundos y mantengo constante el escalado de frecuencias. En el host, configuro el controlador de CPU en „rendimiento“ y reduzco el ruido de los servicios de fondo. En la máquina virtual, reduzco las vCPU al valor real necesario, fijo los procesos críticos (por ejemplo, los subprocesos de E/S de la base de datos) a vCPU fijas y limito los grupos de subprocesos de la aplicación. Lo siguiente se aplica a los servidores web y a los tiempos de ejecución: procesos_trabajadores (Nginx), pm.max_hijos (PHP-FPM) o los grupos de ejecutores JVM no deberían ser mayores que el presupuesto total de núcleos disponible menos la sobrecarga del sistema. Las páginas grandes y las fuentes de temporizadores consistentes reducen la sobrecarga de programación; al mismo tiempo, evito el sobrecompromiso agresivo de RAM para evitar que latencias adicionales de swap entren en el pipeline.

Diseño de la aplicación: contrapresión en lugar de hacinamiento

Contrapresión es la respuesta limpia a la escasez de núcleos. En lugar de almacenar en búfer las avalanchas de peticiones en colas enormes, limito las peticiones procesadas en paralelo a los núcleos más la reserva. Los servicios señalan „ocupado“ en picos de utilización o dan respuestas degradadas pero rápidas (por ejemplo, cachés más cortas, menos detalles). Las bases de datos tienen tiempos de bloqueo más cortos y transacciones más ligeras; las consultas de búsqueda y análisis se ejecutan con un retardo. En los entornos de microservicios, freno en el borde, no en profundidad: las pasarelas API y los límites de entrada evitan que las dependencias internas se colapsen. El resultado son colas ordenadas con colas cortas, exactamente lo que salva la experiencia del usuario en caso de compromiso excesivo.

Migración en vivo y carga de fondo: escollos ocultos

vMotion/Migración en vivo o las ventanas de mantenimiento del host provocan un aumento de las latencias a corto plazo, incluso si el sobrecompromiso es moderado. Mientras se copia la memoria y se sincronizan los estados de la CPU, las franjas horarias y las rutas de E/S se desplazan. Si el evento coincide con ventanas de lotes, los retrasos se acumulan. Planifico las ventanas de migración fuera de las horas punta y aparco los trabajos que se ejecutan en paralelo. También separo estrictamente las copias de seguridad/antivirus/indización de las rutas de latencia, idealmente en mis propias máquinas virtuales con baja prioridad. Así evito que procesos de mantenimiento „bienintencionados“ distorsionen las mediciones de rendimiento o afecten a los flujos de usuarios.

Lista de control: Un diagnóstico claro en 15 minutos

• Seleccione el periodo de tiempo, reproduzca la carga (prueba de carga o ventana de picos).
• Hipervisor: Comprobar CPU Ready por vCPU, Co-Stop, Host Run Queue.
• Invitado: %steal, %iowait, cola de ejecución, cambio de contexto, medición de carga IRQ.
• Sincroniza los pools de hilos y trabajadores de la aplicación con el número de vCPU.
• Identificar y mover los trabajos en segundo plano y las ejecuciones cron.
• Prueba: Reduzca a la mitad o a la mitad el número de vCPU, mida de nuevo Ready/Steal.
• Cuando los valores caen y la latencia se suaviza: Dividir horizontalmente, fijar límites.
• Si no hay mejora: Cambie de host/plan, compruebe los núcleos dedicados.

10 ideas erróneas típicas que cuestan rendimiento

Errores Veo esto regularmente: Más vCPUs no significan automáticamente más velocidad si el host ya está funcionando a una velocidad de reloj baja. Un valor alto de CPU en la VM no requiere una utilización completa del núcleo mientras Ready sea alto y Steal esté aumentando. Las grandes máquinas virtuales SMP no proporcionan necesariamente un mejor paralelismo si dominan la sincronización y los bloqueos. Las funciones de priorización del hipervisor no eliminan los límites físicos; sólo posponen los retrasos. Y el ajuste de bases de datos o PHP sólo oculta brevemente los cuellos de botella si el programador sigue siendo el verdadero cuello de botella.

Pasos concretos: de los síntomas a la causa

Procedimiento Empiezo de forma reproducible: primero defino el escenario de carga, luego registro los tiempos de CPU Ready, Co-Stop, Steal y IO wait en la misma ventana de tiempo. Si las métricas muestran las típicas firmas de overcommit, reduzco el número de vCPUs por VM, distribuyo las cargas de trabajo SMP y muevo los procesos en segundo plano. Si los valores siguen siendo altos, muevo la VM a un host con un ratio bajo o núcleos reservados. Si la latencia sólo cambia entonces, guardo el nuevo perfil como línea de base y anclo las alarmas a valores porcentuales y de milisegundos. De este modo, no resuelvo los síntomas, sino que abordo la causa en la programación.

Brevemente resumido

ResumenEl sobrecompromiso de CPU parece eficiente, pero bajo carga crea colas que ralentizan el servidor virtual. Métricas como CPU Ready Time, Co-Stop y Steal Time indican claramente el problema y proporcionan umbrales objetivos. Red Hat recomienda ratios conservadores y VMs más pequeñas con menos vCPUs, mientras que los datos prácticos de entornos VMware demuestran el impacto en el rendimiento y los tiempos de respuesta [1][3]. Para los sitios web y las API, existe el riesgo de pérdidas de clasificación, rebotes y procesos propensos a errores si la latencia fluctúa [2]. Por lo tanto, confío en la asignación de derechos, la supervisión limpia, los umbrales claros y, si es necesario, los núcleos dedicados o el metal desnudo para mantener la fiabilidad del rendimiento de los VPS.