I Limiti di CPU Uccidono le Prestazioni: È Tempo di Ripensare il Controllo delle Risorse

Informazioni Fondamentali

• ID Articolo: 2510.10747
• Titolo: CPU-Limits kill Performance: Time to rethink Resource Control
• Autori: 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)
• Classificazione: cs.DC (Calcolo Distribuito), cs.OS (Sistemi Operativi), cs.PF (Prestazioni)
• Data di Pubblicazione: Ottobre 2025 (preprint arXiv)
• Link Articolo: https://arxiv.org/abs/2510.10747

Riassunto

Questo articolo mette in discussione il meccanismo fondamentale della gestione delle risorse di calcolo nelle applicazioni cloud-native: i limiti di CPU (CPU-Limits). Nonostante la ricerca accademica e la pratica industriale considerino universalmente i limiti di CPU come necessari, gli autori forniscono prove empiriche dimostrando che i limiti di CPU danneggiano effettivamente le prestazioni delle applicazioni e aumentano i costi. L'articolo sostiene che le applicazioni sensibili alla latenza dovrebbero abbandonare completamente i limiti di CPU, il che richiede un ripensamento fondamentale del ridimensionamento automatico e dei modelli di fatturazione, identificando al contempo i casi d'uso legittimi dei limiti di CPU (come i compiti in background).

Contesto di Ricerca e Motivazione

Definizione del Problema

La gestione delle risorse di CPU per i microservizi containerizzati è un problema centrale nel calcolo cloud. La pratica prevalente attuale consiste nel limitare rigorosamente l'utilizzo di CPU dei container attraverso il meccanismo CPU-Limits (c.limit), implementato mediante cpu.cfs_quota_us di Linux. Tuttavia, gli autori osservano un significativo divario tra la teoria e la pratica nelle distribuzioni reali.

Importanza del Problema

1. Impatto sulle Prestazioni: Il throttling causato dai limiti di CPU provoca un deterioramento drastico della latenza delle applicazioni, potenzialmente innescando guasti a cascata
2. Questioni di Costo: I margini di sicurezza stabiliti per evitare il throttling comportano un sovra-provisioning delle risorse del 25-45%
3. Complessità Operativa: Il personale DevOps deve navigare complessi compromessi tra molteplici limiti di CPU a grana fine

Limitazioni degli Approcci Esistenti

La ricerca esistente sul ridimensionamento automatico (come FIRM, Cilantro, Autothrottle, ecc.) si basa sull'assunto che i limiti di CPU siano necessari, concentrandosi sull'ottimizzazione dei valori di limite piuttosto che sulla messa in discussione del meccanismo stesso. Attraverso l'analisi, gli autori scoprono che questi approcci falliscono quando i limiti di CPU vengono rimossi.

Motivazione della Ricerca

Attraverso interviste con SRE (Site Reliability Engineers) e indagini su discussioni online, gli autori scoprono che la comunità operativa è divisa sui limiti di CPU. Molti professionisti hanno già iniziato a rimuovere i limiti di CPU per migliorare le prestazioni, contrastando con il punto di vista prevalente nel mondo accademico.

Contributi Principali

1. Sfida ai Concetti Tradizionali: Prima messa in discussione sistematica della necessità dei limiti di CPU nelle applicazioni sensibili alla latenza, con prove empiriche sostanziali
2. Analisi delle Prestazioni: Analisi approfondita dei meccanismi negativi dei limiti di CPU su latenza, affidabilità e costo
3. Progettazione di Soluzioni Alternative: Dimostrazione della fattibilità e dei vantaggi della gestione delle risorse utilizzando solo CPU-Requests (c.req)
4. Proposta di Nuovo Paradigma: Presentazione di modelli di fatturazione basati sulle prestazioni e progettazione del ridimensionamento automatico senza limitazioni
5. Implementazione di Prototipo: Costruzione del prototipo YAAS (Yet Another AutoScaler), che realizza un risparmio di risorse del 51%
6. Segmentazione dei Casi d'Uso: Definizione chiara dei casi d'uso legittimi dei limiti di CPU (come compiti in background, applicazioni CPU-bound)

Dettagli Metodologici

Definizione del Compito

L'obiettivo della ricerca è riprogettare il meccanismo di gestione delle risorse di CPU dei container, ottenendo un migliore compromesso prestazioni-costo attraverso l'ottimizzazione dei CPU-Requests e dell'utilizzo dei nodi, senza utilizzare limiti di CPU.

Struttura Argomentativa Principale

Gli autori costruiscono un albero decisionale (Figura 1) per analizzare sistematicamente vari scenari di configurazione dei limiti di CPU:

1. limit = req: Comporta aumento dei costi, richiedendo margini di sicurezza del 25-45%
2. limit > req:
   • Se il limite non viene mai raggiunto, è superfluo
   • Se il limite potrebbe essere raggiunto, causa "sospensione" del ridimensionamento automatico o deterioramento drastico della latenza

Dimostrazione della Sufficienza dei CPU-Requests

Gli autori provano la sufficienza dell'utilizzo solo dei CPU-Requests su due livelli:

Garanzie dello Scheduler CFS: Lo scheduler CFS di Linux fornisce garanzie di equità proporzionale, assicurando che un Pod P_i con CPU-Requests r_i su un nodo con CPU totale C riceva almeno (r_i/Σr_j) × C di tempo di CPU.

Controllo dell'Orchestratore: Gli orchestratori come Kubernetes garantiscono che la somma dei CPU-Requests di tutti i container su un nodo non superi la capacità del nodo, rendendo i CPU-Requests una garanzia minima assoluta.

Progettazione del Prototipo YAAS

YAAS si basa su due variabili di controllo chiave:

1. Overage (U-R): Differenza tra l'utilizzo effettivo e l'allocazione del Pod
2. Utilizzo del Nodo (N): Utilizzo totale di CPU del nodo in cui risiede il Pod

Strategia principale:

• Mantenere overage ≥ 0, aumentando le risorse solo quando l'SLO sta per essere violato
• Ottimizzare l'utilizzo dei nodi attraverso la migrazione dei Pod
• Combinare ridimensionamento verticale e orizzontale

Configurazione Sperimentale

Dataset

Utilizzo di due applicazioni di microservizi da DeathStarBench:

• HotelReservation (HR): Sistema di prenotazione alberghiera
• SocialNetwork (SN): Applicazione di rete sociale

Ambiente Sperimentale

• Piattaforma: Cluster Amazon EC2
• Modelli di Carico: Carico di richieste variabile, simulando ambienti di produzione reali
• Metriche di Valutazione:
  • Latenza end-to-end del percentile 99 (P99)
  • Utilizzo delle risorse di CPU
  • Numero di ridimensionamenti e tempo di convergenza
  • Efficienza dei costi

Metodi di Confronto

• HPA (Horizontal Pod Autoscaler) tradizionale basato su limiti di CPU
• Configurazione manualmente ottimizzata dei limiti di CPU
• Diverse impostazioni di margini di sicurezza (20%-30%)

Risultati Sperimentali

Risultati Principali

Impatto sulla Latenza:

• L'impostazione di limiti di CPU su un solo Pod (su 19 totali) causa un deterioramento della latenza end-to-end di 5 volte
• I limiti di CPU danneggiano le prestazioni attraverso due meccanismi: throttling di singole richieste e formazione di code tra richieste

Analisi dei Costi:

• Evitare il throttling richiede un sovra-provisioning delle risorse del 25-45%
• La semplice rimozione dei limiti di CPU consente un risparmio di risorse del 38%
• YAAS realizza ulteriormente un risparmio di risorse del 51%

Prestazioni del Ridimensionamento:

• Quando il carico aumenta del 25%, l'aumento della soglia di ridimensionamento dal 60% al 70% aumenta il tempo di soddisfacimento dell'SLO di 4 volte
• Dimostra l'impatto dei limiti di CPU sulla sensibilità del ridimensionamento automatico

Esperimenti di Ablazione

Analisi dei Margini di Sicurezza: Diverse applicazioni richiedono diversi margini di sicurezza:

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

Meccanismo di Formazione delle Code: Verifica teorica e sperimentale di come i limiti di CPU formano code a carichi inferiori, mentre i CPU-Requests non producono questo problema.

Analisi di Casi

Scenario Multi-Tenant: Gli esperimenti mostrano che quando due applicazioni coesistono, i CPU-Requests proteggono efficacemente le applicazioni conformi dalle applicazioni con burst, mentre i limiti di CPU peggiorano le prestazioni.

Guasti a Cascata: Le lunghe code causate dai limiti di CPU possono far superare il limite di memoria di un Pod, innescando il riavvio del Pod, che a sua volta causa ad altri Pod di raggiungere i limiti o di superare i timeout delle richieste.

Lavori Correlati

Ricerca sul Ridimensionamento Automatico

L'articolo analizza sistematicamente i lavori recenti sul ridimensionamento automatico dalle principali conferenze, scoprendo che tutti dipendono dai limiti di CPU:

• FIRM: Utilizza l'apprendimento per rinforzo per ottimizzare i limiti di CPU
• Cilantro: Regola l'allocazione delle risorse basandosi su feedback online
• Autothrottle: Approccio a due livelli per gestire gli obiettivi SLO
• Ursa: Gestione delle risorse guidata dall'analisi

Pratica Industriale

• La classificazione QoS di Kubernetes richiede che i container critici impostino limiti di CPU
• I provider di servizi cloud (come GCP Autopilot) applicano automaticamente i limiti di CPU
• Le migliori pratiche multi-tenant consigliano l'utilizzo dei limiti di CPU

Conclusioni e Discussione

Conclusioni Principali

1. I Limiti di CPU Sono Dannosi: Per le applicazioni sensibili alla latenza, i limiti di CPU sono o dannosi (causano throttling) o inutili (non vengono mai raggiunti)
2. I CPU-Requests Sono Sufficienti: Le garanzie degli orchestratori e degli scheduler moderni rendono i CPU-Requests sufficienti per fornire l'isolamento delle risorse
3. Nuovo Spazio di Progettazione: La rimozione dei limiti di CPU apre nuove dimensioni di ottimizzazione basate su overage e utilizzo dei nodi
4. Necessità di Cambio di Paradigma: È necessario riprogettare il ridimensionamento automatico e i modelli di fatturazione

Limitazioni

1. Ambito di Applicabilità: Principalmente focalizzato su applicazioni sensibili alla latenza; scenari come i compiti in background richiedono ancora limiti di CPU
2. Scala Sperimentale: Gli esperimenti si basano su specifici benchmark di microservizi e richiedono una validazione su scala più ampia
3. Distribuzione in Produzione: Il prototipo YAAS richiede ulteriore ingegnerizzazione per l'uso in ambienti di produzione
4. Ecosistema: Richiede cambiamenti coordinati negli orchestratori, nei sistemi di monitoraggio e nei sistemi di fatturazione

Direzioni Future

1. Scheduling Intelligente: Scheduling consapevole delle interferenze che combina risorse microarchitetturali (cache, larghezza di banda della memoria)
2. Fatturazione Basata sulle Prestazioni: Modelli di fatturazione basati sul soddisfacimento dell'SLO piuttosto che sull'utilizzo delle risorse
3. Ridimensionamento Verticale: Ottimizzazione del ridimensionamento verticale in ambienti senza limiti di CPU
4. Ottimizzazione Multi-Dimensionale: Ottimizzazione congiunta del ridimensionamento dei Pod e del ridimensionamento dei nodi

Valutazione Approfondita

Punti di Forza

1. Prospettiva Dirompente: Coraggio nel mettere in discussione gli assunti fondamentali del settore, con significativo valore accademico
2. Prove Empiriche Sostanziali: Supporto multidimensionale della prospettiva attraverso analisi teorica, verifica sperimentale e indagine industriale
3. Valore Pratico: Fornisce soluzioni alternative concrete e implementazione di prototipi, con valore applicativo diretto
4. Analisi Sistematica: Analisi completa del problema da molteplici prospettive: prestazioni, costi, affidabilità
5. Prospettiva Equilibrata: Critica l'uso improprio dei limiti di CPU mentre identifica i casi d'uso legittimi

Insufficienze

1. Limitazioni Sperimentali: Gli esperimenti si basano principalmente su due applicazioni di microservizi, mancando di validazione su tipi di applicazioni più ampi
2. Verifica in Produzione: Mancanza di dati di verifica a lungo termine in ambienti di produzione su larga scala
3. Analisi di Compatibilità: Analisi insufficiente dei costi di trasformazione dei sistemi e delle catene di strumenti esistenti
4. Considerazioni di Sicurezza: Discussione non sufficientemente approfondita dei potenziali rischi di sicurezza della rimozione dei limiti di CPU

Impatto

Impatto Accademico:

• Potrebbe innescare un cambio di paradigma nella ricerca sulla gestione delle risorse
• Fornisce nuove direzioni di progettazione per la ricerca sul ridimensionamento automatico
• Sfida le migliori pratiche industriali consolidate da più di un decennio

Impatto Industriale:

• Fornisce ai provider di servizi cloud nuovi percorsi per l'ottimizzazione dei costi
• Potrebbe influenzare il design futuro di orchestratori come Kubernetes
• Promuove l'innovazione nei modelli di fatturazione basati sulle prestazioni

Scenari di Applicabilità

Applicabilità Diretta:

• Servizi online sensibili alla latenza
• Applicazioni cloud-native sensibili ai costi
• Architetture di microservizi che richiedono garanzie di prestazioni elevate

Richiedono Cautela:

• Ambienti multi-tenant (richiedono meccanismi di isolamento aggiuntivi)
• Carichi di lavoro ibridi contenenti compiti in background
• Scenari con requisiti di conformità rigorosi sull'utilizzo delle risorse

Bibliografia

L'articolo cita 83 lavori correlati, coprendo molteplici settori inclusi orchestrazione di container, gestione delle risorse e ridimensionamento automatico. I riferimenti chiave includono:

• Documentazione ufficiale di Kubernetes e migliori pratiche
• Ricerca recente sul ridimensionamento automatico da conferenze di primo livello (OSDI, NSDI, EuroSys, ecc.)
• Documentazione del kernel Linux su scheduling di CPU e control group
• Esperienza pratica industriale e studi di caso

Questo articolo, con la sua prospettiva dirompente e l'analisi empirica sostanziale, pone una sfida importante al settore della gestione delle risorse cloud-native. Sebbene la rimozione completa dei limiti di CPU potrebbe richiedere una trasformazione diffusa dell'ecosistema, le intuizioni e le soluzioni alternative fornite indicano una nuova direzione per lo sviluppo futuro del settore. Il valore dell'articolo risiede non solo nei contributi tecnici, ma anche nella sua profonda riflessione critica sulle convinzioni consolidate dell'industria.