2025-11-20T20:19:15.373671

CPU-Limits kill Performance: Time to rethink Resource Control

Shetty, Chakraborty, Franke et al.
Research in compute resource management for cloud-native applications is dominated by the problem of setting optimal CPU limits -- a fundamental OS mechanism that strictly restricts a container's CPU usage to its specified CPU-limits . Rightsizing and autoscaling works have innovated on allocation/scaling policies assuming the ubiquity and necessity of CPU-limits . We question this. Practical experiences of cloud users indicate that CPU-limits harms application performance and costs more than it helps. These observations are in contradiction to the conventional wisdom presented in both academic research and industry best practices. We argue that this indiscriminate adoption of CPU-limits is driven by erroneous beliefs that CPU-limits is essential for operational and safety purposes. We provide empirical evidence making a case for eschewing CPU-limits completely from latency-sensitive applications. This prompts a fundamental rethinking of auto-scaling and billing paradigms and opens new research avenues. Finally, we highlight specific scenarios where CPU-limits can be beneficial if used in a well-reasoned way (e.g. background jobs).
academic

CPU-Limits töten Performance: Zeit zum Überdenken der Ressourcenkontrolle

Grundinformationen

  • Paper-ID: 2510.10747
  • Titel: CPU-Limits kill Performance: Time to rethink Resource Control
  • Autoren: 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)
  • Klassifizierung: cs.DC (Verteilte Systeme), cs.OS (Betriebssysteme), cs.PF (Leistung)
  • Veröffentlichungsdatum: Oktober 2025 (arXiv-Preprint)
  • Paper-Link: https://arxiv.org/abs/2510.10747

Zusammenfassung

Dieses Paper stellt einen grundlegenden Mechanismus der CPU-Ressourcenverwaltung (CPU-Limits) in Cloud-nativen Anwendungen in Frage. Obwohl CPU-Limits in der akademischen Forschung und industriellen Praxis allgemein als notwendig angesehen werden, zeigen die Autoren durch empirische Evidenz, dass CPU-Limits tatsächlich die Anwendungsleistung beeinträchtigen und die Kosten erhöhen. Das Paper argumentiert, dass latenzempfindliche Anwendungen CPU-Limits vollständig aufgeben sollten, was eine grundlegende Neubewertung der automatischen Skalierung und Abrechnungsmodelle erfordert. Gleichzeitig werden legitime Anwendungsfälle für CPU-Limits (wie Hintergrundaufgaben) identifiziert.

Forschungshintergrund und Motivation

Problemdefinition

Die CPU-Ressourcenverwaltung containerisierter Microservices ist ein Kernproblem des Cloud Computing. Die aktuelle Standardpraxis besteht darin, die CPU-Nutzung von Containern durch den CPU-Limits-Mechanismus (c.limit) streng zu begrenzen, der auf Linuxs cpu.cfs_quota_us basiert. Die Autoren beobachten jedoch eine erhebliche Diskrepanz zwischen Theorie und Praxis in realen Bereitstellungen.

Bedeutung des Problems

  1. Leistungsauswirkungen: Das durch CPU-Limits verursachte Throttling führt zu drastischer Verschlechterung der Anwendungslatenzen und kann Kaskadenausfälle auslösen
  2. Kostenprobleme: Sicherheitsspannen zur Vermeidung von Throttling führen zu 25-45% Ressourcenüberbereitstellung
  3. Betriebskomplexität: DevOps-Personal muss komplexe Kompromisse zwischen mehreren granularen CPU-Limits abwägen

Limitierungen bestehender Ansätze

Bestehende Forschung zur automatischen Skalierung (wie FIRM, Cilantro, Autothrottle) basiert auf der Annahme, dass CPU-Limits notwendig sind, und konzentriert sich auf die Optimierung von Limitwerten statt auf die Infragestellung des Mechanismus selbst. Die Autoren zeigen durch Analyse, dass diese Ansätze nach Entfernung von CPU-Limits fehlschlagen.

Forschungsmotivation

Durch Interviews mit SREs (Site Reliability Engineers) und Analyse von Online-Diskussionen stellen die Autoren fest, dass die Betriebscommunity über CPU-Limits uneins ist. Viele Praktiker haben bereits begonnen, CPU-Limits zu entfernen, um die Leistung zu verbessern, was im Gegensatz zur akademischen Mainstream-Meinung steht.

Kernbeiträge

  1. Herausforderung konventioneller Ansichten: Erste systematische Infragestellung der Notwendigkeit von CPU-Limits in latenzempfindlichen Anwendungen mit umfassender empirischer Evidenz
  2. Leistungsanalyse: Tiefgehende Analyse der negativen Auswirkungsmechanismen von CPU-Limits auf Latenz, Zuverlässigkeit und Kosten
  3. Entwurf von Alternativen: Nachweis der Machbarkeit und Vorteile der Ressourcenverwaltung nur mit CPU-Requests (c.req)
  4. Neue Paradigmen: Vorschlag leistungsbasierter Abrechnungsmodelle und unbegrenzter Autoscaling-Designs
  5. Prototyp-Implementierung: Konstruktion des YAAS-Prototyps (Yet Another AutoScaler) mit 51% Ressourceneinsparungen
  6. Anwendungsfallabgrenzung: Klare Identifikation legitimer Anwendungsfälle für CPU-Limits (wie Hintergrundaufgaben, CPU-gebundene Workloads)

Methodische Details

Aufgabendefinition

Das Forschungsziel besteht darin, den CPU-Ressourcenverwaltungsmechanismus für Container neu zu gestalten, um ohne CPU-Limits durch Optimierung von CPU-Requests und Knotenauslastung bessere Leistungs-Kosten-Kompromisse zu erreichen.

Kernargumentationsrahmen

Die Autoren konstruieren einen Entscheidungsbaum (Abbildung 1) zur systematischen Analyse verschiedener CPU-Limit-Konfigurationsszenarien:

  1. limit = req: Führt zu Kostenerhöhung, erfordert 25-45% Sicherheitsspanne
  2. limit > req:
    • Wenn das Limit nie erreicht wird, ist es unnötig
    • Wenn das Limit möglicherweise erreicht wird, führt dies zu "Einfrieren" des Autoscalers oder drastischer Latenzver­schlechterung

Nachweis der Ausreichung von CPU-Requests

Die Autoren beweisen die Ausreichung von nur CPU-Requests auf zwei Ebenen:

CFS-Scheduler-Garantien: Der Linux-CFS-Scheduler bietet proportionale Fairness-Garantien, die sicherstellen, dass Pod P_i mit CPU-Requests r_i auf einem Knoten mit insgesamt C CPUs mindestens (r_i/Σr_j) × C CPU-Zeit erhält.

Orchestrator-Gating: Orchestratoren wie Kubernetes stellen sicher, dass die Summe der CPU-Requests aller Container auf einem Knoten die Knotenkapazität nicht überschreitet, wodurch CPU-Requests zu einer absoluten Mindestgarantie werden.

YAAS-Prototyp-Design

YAAS basiert auf zwei Schlüsselkontrollvariablen:

  1. Overage (U-R): Differenz zwischen tatsächlicher Pod-Nutzung und zugewiesener Menge
  2. Knotenauslastung (N): Gesamte CPU-Auslastung des Pods-Knotens

Kernstrategie:

  • Aufrechterhaltung von overage ≥ 0, Ressourcenerhöhung nur bei drohender SLO-Verletzung
  • Optimierung der Knotenauslastung durch Pod-Migration
  • Kombination vertikaler und horizontaler Skalierung

Experimentelle Einrichtung

Datensätze

Verwendung von zwei Microservice-Anwendungen aus DeathStarBench:

  • HotelReservation (HR): Hotelreservierungssystem
  • SocialNetwork (SN): Social-Network-Anwendung

Experimentelle Umgebung

  • Plattform: Amazon EC2-Cluster
  • Lastmuster: Variable Anfragelast, Simulation realer Produktionsumgebungen
  • Bewertungsmetriken:
    • End-to-End-Tail-Latenz (P99)
    • CPU-Ressourcennutzung
    • Skalierungshäufigkeit und Konvergenzzeit
    • Kosteneffizienz

Vergleichsmethoden

  • Traditionaler HPA (Horizontal Pod Autoscaler) basierend auf CPU-Limits
  • Manuell optimierte CPU-Limit-Konfiguration
  • Verschiedene Sicherheitsspannen-Einstellungen (20%-30%)

Experimentelle Ergebnisse

Hauptergebnisse

Latenzauswirkungen:

  • Das Setzen von CPU-Limits auf nur einem Pod (von insgesamt 19) führt zu 5-facher Verschlechterung der End-to-End-Tail-Latenz
  • CPU-Limits schädigen die Leistung durch zwei Mechanismen: Single-Request-Throttling und Request-übergreifende Warteschlangen­bildung

Kostenanalyse:

  • Vermeidung von Throttling erfordert 25-45% Ressourcenüberbereitstellung
  • Einfaches Entfernen von CPU-Limits spart 38% Ressourcen
  • YAAS erreicht weitere 51% Ressourceneinsparungen

Autoscaling-Leistung:

  • Bei 25% Lasterhöhung führt die Erhöhung des Skalierungsschwellwerts von 60% auf 70% zu 4-facher Erhöhung der SLO-Erfüllungszeit
  • Zeigt die Auswirkungen von CPU-Limits auf die Autoscaling-Empfindlichkeit

Ablationsexperimente

Sicherheitsspannen-Analyse: Verschiedene Anwendungen erfordern unterschiedliche Sicherheitsspannen:

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

Warteschlangen­bildungsmechanismus: Theoretische Analyse und experimentelle Validierung zeigen, wie CPU-Limits bei niedrigerer Last Warteschlangen bilden, während CPU-Requests dieses Problem nicht verursachen.

Fallstudien

Multi-Tenant-Szenario: Experimente zeigen, dass CPU-Requests konforme Anwendungen effektiv vor Burst-Anwendungen schützen können, während CPU-Limits die Leistung tatsächlich verschlechtern.

Kaskadenausfälle: Durch CPU-Limits verursachte lange Warteschlangen können Pod-Speicher überschreiten, Pod-Neustarts auslösen und andere Pods zu Limits oder Request-Timeouts führen.

Verwandte Arbeiten

Autoscaling-Forschung

Das Paper analysiert systematisch aktuelle Autoscaling-Arbeiten von Top-Konferenzen und stellt fest, dass sie alle von der Notwendigkeit von CPU-Limits abhängen:

  • FIRM: Verwendet Reinforcement Learning zur Optimierung von CPU-Limits
  • Cilantro: Passt Ressourcenallokation basierend auf Online-Feedback an
  • Autothrottle: Zweischichtiger Ansatz für SLO-Ziele
  • Ursa: Analysgetriebene Ressourcenverwaltung

Industrielle Praxis

  • Kubernetes-QoS-Klassifizierung erfordert CPU-Limits für kritische Container
  • Cloud-Anbieter (wie GCP Autopilot) wenden CPU-Limits automatisch an
  • Best Practices für Multi-Tenancy empfehlen die Verwendung von CPU-Limits

Schlussfolgerungen und Diskussion

Hauptschlussfolgerungen

  1. CPU-Limits sind schädlich: Für latenzempfindliche Anwendungen sind CPU-Limits entweder schädlich (verursachen Throttling) oder nutzlos (werden nie erreicht)
  2. CPU-Requests sind ausreichend: Die Garantien moderner Orchestratoren und Scheduler machen CPU-Requests für Ressourcenisolation ausreichend
  3. Neuer Designraum: Das Entfernen von CPU-Limits eröffnet neue Optimierungsdimensionen basierend auf Overage und Knotenauslastung
  4. Paradigmenwechsel erforderlich: Neuentwurf von Autoscaling und Abrechnungsmodellen notwendig

Limitierungen

  1. Anwendungsbereich: Konzentriert sich hauptsächlich auf latenzempfindliche Anwendungen; Hintergrundaufgaben benötigen weiterhin CPU-Limits
  2. Experimentskala: Experimente basieren auf spezifischen Microservice-Benchmarks und benötigen umfassendere Validierung
  3. Produktionsbereitstellung: Der YAAS-Prototyp benötigt weitere Entwicklung für Produktionsumgebungen
  4. Ökosystem: Erfordert koordinierte Änderungen in Orchestratoren, Monitoring und Abrechnungssystemen

Zukünftige Richtungen

  1. Intelligente Planung: Interferenzbedingte Planung unter Berücksichtigung von Mikroarchitektur-Ressourcen (Cache, Speicherbandbreite)
  2. Leistungsbasierte Abrechnung: Abrechnungsmodelle basierend auf SLO-Erfüllung statt Ressourcennutzung
  3. Vertikale Skalierung: Optimierung der vertikalen Skalierung in CPU-Limit-freien Umgebungen
  4. Multidimensionale Optimierung: Gemeinsame Optimierung von Pod- und Knoten-Skalierung

Tiefgehende Bewertung

Stärken

  1. Disruptive Perspektive: Mut, grundlegende Annahmen des Feldes zu hinterfragen, mit bedeutendem akademischem Wert
  2. Ausreichende Evidenz: Multidimensionale Unterstützung durch theoretische Analyse, experimentelle Validierung und industrielle Forschung
  3. Praktischer Wert: Bietet konkrete Alternativen und Prototyp-Implementierungen mit direktem Anwendungswert
  4. Systematische Analyse: Umfassende Analyse des Problems aus Leistungs-, Kosten- und Zuverlässigkeitsperspektiven
  5. Ausgewogene Sichtweise: Kritisiert den Missbrauch von CPU-Limits, identifiziert aber auch legitime Anwendungsfälle

Schwächen

  1. Experimentelle Limitierungen: Experimente basieren hauptsächlich auf zwei Microservice-Anwendungen, benötigen Validierung über breitere Anwendungstypen
  2. Produktionsvalidierung: Mangel an langfristigen Validierungsdaten aus großflächigen Produktionsumgebungen
  3. Kompatibilität: Unzureichende Analyse der Transformationskosten für bestehende Systeme und Toolketten
  4. Sicherheitsüberlegungen: Unzureichende Diskussion potenzieller Sicherheitsrisiken beim Entfernen von CPU-Limits

Auswirkungen

Akademische Auswirkungen:

  • Könnte einen Paradigmenwechsel in der Ressourcenverwaltungsforschung auslösen
  • Bietet neue Designperspektiven für Autoscaling-Forschung
  • Hinterfragt über ein Jahrzehnt etablierte Best Practices der Industrie

Industrielle Auswirkungen:

  • Bietet Cloud-Anbietern neue Wege zur Kostenoptimierung
  • Könnte das zukünftige Design von Orchestratoren wie Kubernetes beeinflussen
  • Fördert Innovation in leistungsbasierten Abrechnungsmodellen

Anwendungsszenarien

Direkt anwendbar:

  • Latenzempfindliche Online-Dienste
  • Kostenempfindliche Cloud-native Anwendungen
  • Microservice-Architekturen mit hohen Leistungsgarantie-Anforderungen

Erfordert Vorsicht:

  • Multi-Tenant-Umgebungen (benötigen zusätzliche Isolationsmechanismen)
  • Gemischte Workloads mit Hintergrundaufgaben
  • Szenarien mit strikten Compliance-Anforderungen für Ressourcennutzung

Literaturverzeichnis

Das Paper zitiert 83 verwandte Arbeiten, die wichtige Forschungen in Container-Orchestrierung, Ressourcenverwaltung und Autoscaling abdecken. Schlüsselreferenzen umfassen:

  • Kubernetes-Dokumentation und Best Practices
  • Aktuelle Autoscaling-Forschung von Top-Konferenzen (OSDI, NSDI, EuroSys, etc.)
  • Linux-Kernel-CPU-Scheduling und Control-Group-Dokumentation
  • Industrielle Praxiserfahrungen und Fallstudien

Dieses Paper stellt mit seinen disruptiven Perspektiven und umfassenden empirischen Analysen eine wichtige Herausforderung für die Cloud-native Ressourcenverwaltung dar. Obwohl die vollständige Entfernung von CPU-Limits möglicherweise umfassende Ökosystem-Veränderungen erfordert, bieten die bereitgestellten Erkenntnisse und Alternativen neue Richtungen für die zukünftige Entwicklung des Feldes. Der Wert des Papers liegt nicht nur in seinen technischen Beiträgen, sondern auch in seiner tiefgreifenden Reflexion über etablierte Branchenüberzeugungen.