Come misurare l'overselling StealTime di EC2 nel cloud pubblico
Misura EC2 Steal Time con mpstat, identifica overselling e vicini rumorosi
Uno Steal Time elevato non equivale a overselling; è necessario valutare insieme a Nitro e al meccanismo dei crediti.
Verifica dell'overselling con mpstat
Per misurare lo Steal Time su un EC2 nel cloud pubblico, il metodo più diretto è osservare %steal per alcuni cicli con mpstat -P ALL 1. Ma non gridare all'overselling appena vedi un numero alto — ci sono cascato: quando i crediti CPU di un'istanza T3 si esauriscono, %steal può salire oltre il 30%, ma non è colpa dei vicini che rubano CPU, è il pool di crediti che è vuoto. Per distinguere realmente tra overhead di scheduling normale sotto virtualizzazione Nitro, esaurimento dei crediti Burstable e contesa da vicini ostili, bisogna incrociare i dati con /proc/schedstat e la metrica CPUCreditBalance di CloudWatch.
In pratica sono solito eseguire prima sudo apt install sysstat && mpstat 1 5, concentrandomi su se %steal supera costantemente il 10%. Se è solo un picco momentaneo, nella maggior parte dei casi è una normale competizione per le risorse CPU dell'host; se invece rimane a lungo su valori alti e la quota di tempo steal in cpustat è stabile, allora sospetto un overselling. Nota: Steal Time alto non equivale a overselling — potrebbe anche essere che hai comprato un'istanza troppo piccola: con l'opzione Unlimited attiva su un'istanza T3, un carico costantemente elevato consuma in anticipo i crediti futuri, e il sintomo è un aumento dello steal.
Ma non è tutto. Di solito esporto l'output di mpstat in CSV e lo impacchetto in un PDF insieme agli screenshot di CloudWatch — se dovessi aprire un ticket di reclamo, queste sono prove concrete. Le istanze condivise di AWS sembrano convenienti, ma quando fai i conti con il FinOps devi convertire il rischio di steal in un premio di rischio: con 4 vCPU, invece di affidarti alla fortuna e contendere le risorse ai vicini, conviene calcolare la differenza di costo a lungo termine tra un Dedicated Host e un'istanza condivisa.
Per l'approccio di audit completo, consulta la Guida all'ispezione EC2 StealTime, oppure entra direttamente nel Console di audit operativo per eseguire automaticamente una verifica.
Oversubscription Nitro e crediti T3
L'architettura Nitro di AWS EC2 è diversa dal normale oversubscription KVM: la schedulazione CPU di Nitro è più isolata in modo rigido, ma l'host condiviso presenta comunque contesa tra vicini. Ciò che confonde davvero sono le istanze burst come T3/T3a/T4g. Quando i crediti CPU sono esauriti e Unlimited non è attivo, le prestazioni vengono riportate forzatamente alla baseline; in questo momento %steal in mpstat non necessariamente aumenta, anzi sembra più un “rallentamento” proprio. Con Unlimited attivo, i crediti possono essere sfruttati in negativo, ma si generano costi aggiuntivi.
Quindi, durante l'analisi, campiona prima con mpstat 1, poi confronta con la metrica CPUCreditBalance di CloudWatch. Se il steal è alto ma i crediti sono sufficienti, è evidenza di oversubscription; altrimenti potrebbe essere normale overhead della virtualizzazione Nitro. Nei test reali, se il steal è costantemente alto, si consiglia di raccogliere prove timestamp da /proc/stat, per presentare ticket o argomentare il downgrade — del resto, dal punto di vista FinOps, pagare per l'oversubscription significa un premio non conveniente.
Ticket forense e premio FinOps
Quando su EC2 rilevi un alto steal time persistente, non avere fretta di accusare AWS di overselling. La mia abitudine: prima usa mpstat -P ALL 1 per campionare continuamente per 15 minuti, poi confronta CPUCreditBalance e CPUCreditUsage di CloudWatch. Se il saldo dei crediti T3/T4g arriva a zero, lo steal time alto è per lo più dovuto all'esaurimento dei crediti CPU, non a un vicino rumoroso. Per confermare davvero il "vicino cattivo", bisogna vedere se sotto virtualizzazione Nitro steal supera il 5% e con irq in aumento—ma Nitro ha di per sé un piccolo overhead di scheduling, quindi non applicare la soglia dello 0,5% tipica dei VPS.
In fase di raccolta prove, esporto contemporaneamente le metriche CloudWatch CPUUtilization e StealTime (lo StealTime su EC2 è un namespace personalizzato, va estratto con GetMetricData), poi uso uno snapshot /proc per registrare la riga cpu. Combino questi tre elementi per timestamp in un PDF e lo allego direttamente al ticket. Quando il supporto AWS vede dati con timeline e screenshot, di solito è più disposto a controllare l'host sottostante—anche se raramente ammettono l'overselling, ma ti sostituiscono l'istanza o ti riorganizzano il placement group.
Infine, il premio FinOps: con la stessa specifica c7i.large su host condiviso per batch processing, istanze con steal time del 3% e dell'8% possono avere una differenza di throughput reale superiore al 12%. Se si considerano i costi aggiuntivi dopo l'esaurimento dei crediti (T series unlimited), il costo complessivo può essere più alto di un host dedicato. Suggerisco di includere lo steal time nel report mensile dei costi, convertendo oltre il 5% come "premio per perdita di prestazioni", e poi confrontarlo con il prezzo annuale di Dedicated Host—spesso, per i task critici, passare a un host dedicato risulta più conveniente.
FAQ
Come si misura lo StealTime di EC2?
Usa i comandi top o vmstat per visualizzare la percentuale di steal della CPU, ad esempio il campo %st in top.
Uno StealTime alto significa sempre overselling?
Non necessariamente. Bisogna considerare l'architettura Nitro e il meccanismo dei crediti; uno StealTime alto potrebbe essere dovuto a contesa temporanea delle risorse.
Come si rileva l'overselling nell'architettura Nitro?
Tramite API AWS, interroga il rapporto tra CPU fisica sottostante e vCPU dell'istanza, confrontando l'allocazione effettiva.
In che modo il meccanismo dei crediti influisce sullo StealTime?
Quando i crediti delle istanze burstable di serie T si esauriscono, la CPU viene limitata e ciò può aumentare lo StealTime; è necessario controllare il saldo dei crediti.
Quali sono i passaggi per determinare in modo complessivo l'overselling?
Prima misura lo StealTime, poi controlla le risorse fisiche dell'istanza Nitro e infine analizza l'uso dei crediti, per arrivare a una conclusione complessiva.