Los Límites de CPU Matan el Rendimiento: Tiempo de Repensar el Control de Recursos

Información Básica

• ID del Artículo: 2510.10747
• Título: CPU-Limits kill Performance: Time to rethink Resource Control
• Autores: Chirag Shetty (UIUC), Sarthak Chakraborty (UIUC), Hubertus Franke (IBM Research), Larisa Shwartz (IBM Research), Chandra Narayanaswami (IBM Research), Indranil Gupta (UIUC), Saurabh Jha (IBM Research)
• Clasificación: cs.DC (Computación Distribuida), cs.OS (Sistemas Operativos), cs.PF (Rendimiento)
• Fecha de Publicación: Octubre de 2025 (preimpresión arXiv)
• Enlace del Artículo: https://arxiv.org/abs/2510.10747

Resumen

Este artículo cuestiona fundamentalmente el mecanismo central en la gestión de recursos computacionales de aplicaciones nativas de la nube: los límites de CPU (CPU-Limits). Aunque la investigación académica y la práctica industrial consideran ampliamente que los límites de CPU son necesarios, los autores proporcionan evidencia empírica demostrando que los límites de CPU en realidad degradan el rendimiento de las aplicaciones e incrementan los costos. El artículo argumenta que las aplicaciones sensibles a la latencia deberían abandonar completamente los límites de CPU, lo que requiere un replanteamiento fundamental del escalado automático y los modelos de facturación, mientras señala los usos legítimos de los límites de CPU en escenarios específicos (como tareas en segundo plano).

Antecedentes de Investigación y Motivación

Definición del Problema

La gestión de recursos de CPU en microservicios containerizados es un problema central en la computación en la nube. La práctica predominante actual es limitar estrictamente el uso de CPU de los contenedores mediante el mecanismo CPU-Limits (c.limit), implementado a través de cpu.cfs_quota_us de Linux. Sin embargo, los autores observan una desconexión significativa entre la teoría y la práctica en las implementaciones reales.

Importancia del Problema

1. Impacto en el Rendimiento: El throttling causado por límites de CPU provoca una degradación drástica de la latencia de las aplicaciones, pudiendo incluso desencadenar fallos en cascada
2. Problemas de Costo: Los márgenes de seguridad establecidos para evitar throttling resultan en un sobreaprovisionamiento de recursos del 25-45%
3. Complejidad Operativa: El personal de DevOps debe navegar compensaciones complejas entre múltiples límites de CPU de grano fino

Limitaciones de Métodos Existentes

La investigación existente sobre escalado automático (como FIRM, Cilantro, Autothrottle, etc.) se construye sobre la suposición de que los límites de CPU son necesarios, enfocándose en optimizar valores de límites en lugar de cuestionar el mecanismo en sí. Los autores descubren mediante análisis que todos estos métodos fallan cuando se eliminan los límites de CPU.

Motivación de la Investigación

A través de entrevistas con SRE (Ingenieros de Confiabilidad del Sitio) e investigación de discusiones en línea, los autores encuentran que la comunidad operativa tiene opiniones divididas sobre los límites de CPU. Muchos profesionales ya han comenzado a eliminar límites de CPU para mejorar el rendimiento, lo que contrasta con la opinión predominante en la academia.

Contribuciones Principales

1. Desafío a Concepciones Tradicionales: Primer cuestionamiento sistemático de la necesidad de límites de CPU en aplicaciones sensibles a la latencia, con evidencia empírica suficiente
2. Análisis de Rendimiento: Análisis profundo de los mecanismos de impacto negativo de los límites de CPU en latencia, confiabilidad y costo
3. Diseño de Alternativas: Demostración de la viabilidad y ventajas de la gestión de recursos utilizando solo CPU-Requests (c.req)
4. Propuesta de Nuevo Paradigma: Presentación de modelos de facturación basados en rendimiento y diseño de escalado automático sin restricciones
5. Implementación de Prototipo: Construcción del prototipo YAAS (Yet Another AutoScaler), logrando ahorros de recursos del 51%
6. Delimitación de Casos de Uso: Definición clara de escenarios de uso legítimo para límites de CPU (como tareas en segundo plano, aplicaciones vinculadas a CPU, etc.)

Explicación Detallada de Métodos

Definición de Tareas

El objetivo de investigación es rediseñar el mecanismo de gestión de recursos de CPU de contenedores, logrando un mejor equilibrio rendimiento-costo mediante la optimización de CPU-Requests y la utilización de nodos, sin utilizar límites de CPU.

Marco de Argumentación Central

Los autores construyen un árbol de decisión (Figura 1) para analizar sistemáticamente varios escenarios de configuración de límites de CPU:

1. limit = req: Conduce a aumento de costos, requiriendo márgenes de seguridad del 25-45%
2. limit > req:
   • Si el límite nunca se alcanza, es innecesario
   • Si el límite puede alcanzarse, causa que el escalado automático se "bloquee" o provoca degradación drástica de latencia

Demostración de Suficiencia de CPU-Requests

Los autores demuestran la suficiencia del uso exclusivo de CPU-Requests en dos niveles:

Garantías del Planificador CFS: El planificador CFS de Linux proporciona garantías de equidad proporcional, asegurando que un Pod P_i con CPU-Requests r_i en un nodo con CPU total C obtenga al menos (r_i/Σr_j) × C de tiempo de CPU.

Control del Orquestador: Los orquestadores como Kubernetes aseguran que la suma total de CPU-Requests de todos los contenedores en un nodo no exceda la capacidad del nodo, haciendo que CPU-Requests sea una garantía mínima absoluta.

Diseño del Prototipo YAAS

YAAS se basa en dos variables de control clave:

1. Exceso (U-R): Diferencia entre el uso real del Pod y la cantidad asignada
2. Utilización del Nodo (N): Utilización total de CPU del nodo donde reside el Pod

Estrategia central:

• Mantener exceso ≥ 0, incrementando recursos solo cuando el SLO está a punto de violarse
• Optimizar utilización del nodo mediante migración de Pods
• Combinar escalado vertical y horizontal

Configuración Experimental

Conjunto de Datos

Utiliza dos aplicaciones de microservicios de DeathStarBench:

• HotelReservation (HR): Sistema de reserva de hoteles
• SocialNetwork (SN): Aplicación de red social

Entorno Experimental

• Plataforma: Clúster Amazon EC2
• Patrones de Carga: Carga de solicitudes variable, simulando entornos de producción reales
• Métricas de Evaluación:
  • Latencia de cola (P99) de extremo a extremo
  • Uso de recursos de CPU
  • Número de escalados y tiempo de convergencia
  • Eficiencia de costos

Métodos de Comparación

• HPA (Horizontal Pod Autoscaler) tradicional basado en límites de CPU
• Configuración de límites de CPU optimizada manualmente
• Diferentes configuraciones de márgenes de seguridad (20%-30%)

Resultados Experimentales

Resultados Principales

Impacto en Latencia:

• Establecer límites de CPU en solo un Pod (de 19 totales) causa degradación de latencia de cola de extremo a extremo de 5 veces
• Los límites de CPU dañan el rendimiento mediante dos mecanismos: throttling de solicitud individual y formación de colas entre solicitudes

Análisis de Costo:

• Evitar throttling requiere sobreaprovisionamiento de recursos del 25-45%
• La simple eliminación de límites de CPU ahorra 38% de recursos
• YAAS logra ahorros adicionales del 51% de recursos

Rendimiento del Escalado Automático:

• Cuando la carga aumenta un 25%, elevar el umbral de escalado del 60% al 70% aumenta el tiempo de cumplimiento de SLO en 4 veces
• Demuestra el impacto de los límites de CPU en la sensibilidad del escalado automático

Experimentos de Ablación

Análisis de Margen de Seguridad: Diferentes aplicaciones requieren márgenes de seguridad distintos:

• nginx-thrift: 30%
• user-timeline-service: 45%

Mecanismo de Formación de Colas: Verificación teórica y experimental de cómo los límites de CPU forman colas con cargas bajas, mientras que CPU-Requests no produce este problema.

Análisis de Casos

Escenario Multiinquilino: Los experimentos muestran que cuando dos aplicaciones coexisten, CPU-Requests puede proteger efectivamente aplicaciones conformes de aplicaciones que explotan recursos, mientras que los límites de CPU empeoran el rendimiento.

Fallos en Cascada: Las colas largas causadas por límites de CPU pueden hacer que la memoria del Pod se agote, provocando reinicio del Pod, lo que a su vez causa que otros Pods alcancen límites o superen tiempos de espera de solicitud.

Trabajo Relacionado

Investigación sobre Escalado Automático

El artículo analiza sistemáticamente trabajos recientes sobre escalado automático en conferencias de primer nivel, descubriendo que todos dependen de límites de CPU:

• FIRM: Utiliza aprendizaje por refuerzo para optimizar límites de CPU
• Cilantro: Ajusta asignación de recursos basado en retroalimentación en línea
• Autothrottle: Enfoque de dos capas para objetivos de SLO
• Ursa: Gestión de recursos impulsada por análisis

Práctica Industrial

• La clasificación de QoS de Kubernetes requiere que contenedores críticos establezcan límites de CPU
• Proveedores de servicios en la nube (como GCP Autopilot) aplican automáticamente límites de CPU
• Las mejores prácticas multiinquilino recomiendan usar límites de CPU

Conclusiones y Discusión

Conclusiones Principales

1. Los Límites de CPU son Perjudiciales: Para aplicaciones sensibles a la latencia, los límites de CPU son perjudiciales (causando throttling) o inútiles (nunca se alcanzan)
2. CPU-Requests es Suficiente: Las garantías de orquestadores y planificadores modernos hacen que CPU-Requests sea suficiente para proporcionar aislamiento de recursos
3. Nuevo Espacio de Diseño: La eliminación de límites de CPU abre nuevas dimensiones de optimización basadas en exceso y utilización de nodos
4. Necesidad de Cambio de Paradigma: Se requiere rediseño de escalado automático y modelos de facturación

Limitaciones

1. Alcance de Aplicabilidad: Enfocado principalmente en aplicaciones sensibles a la latencia; escenarios como tareas en segundo plano aún requieren límites de CPU
2. Escala Experimental: Los experimentos se basan en puntos de referencia de microservicios específicos, requiriendo validación a mayor escala
3. Despliegue en Producción: El prototipo YAAS requiere ingeniería adicional para uso en entornos de producción
4. Ecosistema: Se requiere cambio coordinado en orquestadores, monitoreo y sistemas de facturación

Direcciones Futuras

1. Planificación Inteligente: Planificación consciente de interferencias combinando recursos de microarquitectura (caché, ancho de banda de memoria)
2. Facturación Basada en Rendimiento: Modelos de facturación basados en cumplimiento de SLO en lugar de uso de recursos
3. Escalado Vertical: Optimización de escalado vertical en entornos sin límites de CPU
4. Optimización Multidimensional: Optimización conjunta de escalado de Pods y escalado de nodos

Evaluación Profunda

Fortalezas

1. Perspectiva Disruptiva: Audacia para cuestionar suposiciones fundamentales del dominio, con valor académico importante
2. Evidencia Empírica Suficiente: Apoyo multidimensional mediante análisis teórico, verificación experimental e investigación industrial
3. Valor Práctico: Proporciona soluciones alternativas concretas e implementación de prototipo con valor de aplicación directa
4. Análisis Sistemático: Análisis integral del problema desde múltiples perspectivas: rendimiento, costo y confiabilidad
5. Perspectiva Equilibrada: Critica el uso indebido de límites de CPU mientras señala escenarios de uso legítimo

Insuficiencias

1. Limitaciones Experimentales: Los experimentos se basan principalmente en dos aplicaciones de microservicios, careciendo de validación en tipos de aplicaciones más amplios
2. Verificación en Producción: Falta de datos de verificación a largo plazo en entornos de producción a gran escala
3. Análisis de Compatibilidad: Análisis insuficiente del costo de transformación de sistemas y cadenas de herramientas existentes
4. Consideraciones de Seguridad: Discusión insuficiente de riesgos de seguridad potenciales de eliminar límites de CPU

Impacto

Impacto Académico:

• Puede desencadenar un cambio de paradigma en el campo de la gestión de recursos
• Proporciona nuevas perspectivas de diseño para investigación en escalado automático
• Desafía las mejores prácticas de la industria de más de una década

Impacto Industrial:

• Proporciona a proveedores de servicios en la nube nuevas vías para optimización de costos
• Puede influir en el diseño futuro de orquestadores como Kubernetes
• Impulsa innovación en modelos de facturación basados en rendimiento

Escenarios de Aplicabilidad

Aplicabilidad Directa:

• Servicios en línea sensibles a la latencia
• Aplicaciones nativas de la nube sensibles a costos
• Arquitecturas de microservicios que requieren garantías de alto rendimiento

Requiere Precaución:

• Entornos multiinquilino (requiere mecanismos de aislamiento adicionales)
• Cargas de trabajo híbridas que incluyen tareas en segundo plano
• Escenarios con requisitos de cumplimiento estricto de uso de recursos

Referencias

El artículo cita 83 referencias relacionadas, cubriendo trabajos importantes en múltiples dominios incluyendo orquestación de contenedores, gestión de recursos y escalado automático. Las referencias clave incluyen:

• Documentación oficial de Kubernetes y mejores prácticas
• Investigación reciente sobre escalado automático en conferencias de primer nivel (OSDI, NSDI, EuroSys, etc.)
• Documentación del kernel de Linux relacionada con planificación de CPU y grupos de control
• Experiencia práctica industrial y estudios de casos

Este artículo, con su perspectiva disruptiva y análisis empírico suficiente, presenta un desafío importante a la gestión de recursos de computación nativa de la nube. Aunque la eliminación completa de límites de CPU puede requerir cambios generalizados en el ecosistema, proporciona información y soluciones alternativas que señalan nuevas direcciones para el desarrollo futuro del campo. El valor del artículo no solo radica en sus contribuciones técnicas, sino también en su reflexión profunda sobre las concepciones establecidas de la industria.