Prestazioni dei server cloud e specifiche gonfiate: riconoscere ed evitare le CPU obsolete
Tre prove per smascherare la menzogna del sovrapprezzo delle CPU obsolete
Usa Steal Time + cache del disco + benchmark reali per una tripla verifica, rifiuta di pagare un sovrapprezzo per CPU obsolete.
Quanto il benchmark reale si discosta da quello dichiarato
Il divario tra i benchmark dei server cloud e la configurazione dichiarata è spesso più ampio di quanto si pensi. In particolare, alcune CPU datate che vantano "alta frequenza", come le Xeon E5-2690 v4 e E5-2680 v4, risalenti al 2016 circa, mostrano frequenze single-core non basse, ma in realtà il punteggio single-thread è circa la metà delle nuove generazioni Xeon. Le cause principali del "gonfiamento" dei benchmark sono due: la differenza generazionale dell'hardware e l'impennata dello Steal Time dovuta all'overselling.
Dopo la virtualizzazione su piattaforme datate, il campo steal in /proc/stat ti dice il tempo di CPU sottratto dall'hypervisor. Se con mpstat -P ALL 1 vedi un %steal costantemente superiore al 10%, significa che i vicini stanno contendendo le risorse; in tal caso, non importa quanto sia alta la specifica dichiarata, i benchmark saranno instabili. Un altro indicatore subdolo è il precipizio della cache disco: con CPU datate e storage datato, quando la cache si esaurisce, gli IOPS crollano drasticamente, e nella curva del benchmark si nota una discesa evidente.
Per quantificare il divario, puoi eseguire yabs o sysbench cpu --threads=1 run e confrontare con le specifiche ufficiali. Ho incontrato una piattaforma datata dichiarata a 3.5 GHz, che in realtà aveva un punteggio single-core inferiore del 40% rispetto a una nuova piattaforma a 2.9 GHz. In altre parole, circa la metà di ciò che paghi per "alta frequenza + configurazione datata" è un sovrapprezzo per hardware usato. Questo è proprio il costo negativo più tipico del FinOps: a parità di budget, scegliere nuove piattaforme o istanze certificate ufficialmente offre un costo per unità di calcolo inferiore.
Quindi, non guardare solo le specifiche dichiarate. Ti consiglio di filtrare le istanze in base al benchmark reale e alle soglie di Steal Time su CloudWorth, investendo il budget in prestazioni reali.
Steal Time per smascherare l'overselling
Per capire se la configurazione del cloud server è gonfiata, il primo passo è controllare lo steal time. Questo indicatore è il segnale che l'hypervisor ti manda: quando la CPU fisica viene data dal proprietario a una VM vicina, la tua vCPU deve solo aspettare. Usa top, premi C per passare alla lista CPU, poi t per vedere la colonna steal, oppure esegui direttamente vmstat 1 e osserva il campo st. Campiona per qualche minuto: se la media di st supera il 5%, o addirittura ci sono picchi che arrivano al 20%+, congratulazioni, stai condividendo lo stesso core fisico con un gruppo di cattivi vicini.
# Campiona 10 volte, con intervallo di 1 secondo, calcola la media di st
vmstat 1 10 | awk 'NR>3 {sum+=$16} END {print "avg steal:", sum/(NR-3), "%"}'I picchi di Steal Time sono più preoccupanti di un valore alto e costante: indicano che l'overselling è dinamico e che nelle ore di punta i tuoi tempi di risposta diventano un elettrocardiogramma irregolare. Combinato con il crollo della cache disco menzionato nella sezione precedente, conferma praticamente che si tratta di un host su una vecchia macchina fisica subaffittato più volte.
Da una prospettiva FinOps, è una classica frode da sovrapprezzo: paghi come se fosse hardware nuovo, ma ottieni i resti di una vecchia CPU sminuzzata, con un sovrapprezzo che arriva quasi al triplo del cloud pubblico. Non fidarti dell'alta frequenza: anche se i vecchi Xeon hanno core potenti, non reggono la concorrenza dei vicini. Prima di fare benchmark, controlla lo steal, altrimenti anche i numeri di Geekbench più belli sono solo un miraggio nella sandbox dell'overselling. Questo indicatore è gratuito e riproducibile, più onesto di qualsiasi promessa del venditore.
Prova del precipizio della cache disco
In precedenza usavamo Steal Time per individuare l'overbooking, ma alcuni vecchi data center appiattiscono la pianificazione della CPU, quindi i dati Steal non appaiono così male. In questo momento, non avere fretta di trarre conclusioni: sposta l'attenzione sulla cache del disco, che è uno degli hardware che non mente mai.
In pratica, sono abituato a eseguire fio due volte di seguito: prima misuro la scrittura bufferizzata con Page Cache, poi misuro la scrittura diretta saltando la cache. I comandi sono più o meno questi:
# Prima passata: scrittura bufferizzata (usa la cache di memoria)
fio --name=cache-test --rw=write --bs=1M --size=2G --direct=0 --ioengine=libaio --runtime=30 --time_based
# Seconda passata: scrittura diretta (salta la cache, scrive direttamente su disco)
fio --name=direct-test --rw=write --bs=1M --size=2G --direct=1 --ioengine=libaio --runtime=30 --time_basedL'attenzione è sul "rapporto di precipitazione" tra i due valori. Su un nuovo cloud disk NVMe, la scrittura diretta è circa il 60%-80% della scrittura bufferizzata; su vecchi dischi meccanici o storage condiviso, la scrittura diretta può scendere sotto il 10%. Se il valore nominale è 2000 MB/s ma la scrittura diretta è solo 150 MB/s, è il tipico crollo della cache: i dati prima ti ingannano, ma quando vengono scritti su disco si vede il fondo.
Questa prova va letta insieme a Steal Time. Un valore Steal alto indica che i vicini stanno rubando CPU, il crollo del disco indica che il canale di storage è congestionato: mettendo insieme le due evidenze, si può fondamentalmente giudicare l'overbooking, e non un overbooking qualsiasi, ma quello in cui anche l'hardware sottostante è antiquato.
Da una prospettiva FinOps, queste macchine dovrebbero essere valutate in base al "valore residuo". Se il tasso di premio rispetto alla configurazione dichiarata supera il 30% di una macchina nuova, taglia direttamente; se non puoi tagliare, cambia. Dopotutto, ciò per cui paghi è la spec, non un miraggio nella cache. Per la lista completa delle insidie, consulta la guida alla verifica delle spec gonfiate per i server cloud.
Tasso di sovrapprezzo e albero decisionale per evitare trappole
Quando ricevi un server cloud con una "vecchia CPU ad alta frequenza", non avere fretta di pagare. Per prima cosa calcola il tasso di sovrapprezzo: (pagamento mensile effettivo - prezzo di mercato di una nuova CPU con la stessa configurazione) / prezzo di mercato di una nuova CPU con la stessa configurazione. Se il sovrapprezzo supera il 30%, puoi essere quasi certo che stai pagando una tassa sull'intelligenza per hardware dismesso. Una mossa ancora più aggressiva è quantificarla dal punto di vista FinOps: con gli stessi soldi puoi acquistare un AMD EPYC con il doppio dei core o un Intel più nuovo di tre anni? Se sì, significa che questo acquisto non dovrebbe superare la revisione.
Poi segui il mio albero decisionale a tre livelli:
- Steal Time per scovare il vicino che ruba
vmstat 1 10 | awk '{print $17}' # guarda la colonna stIn campionamenti continui, se la media di st è > 5% o compaiono picchi superiori al 20%, significa che l'host è fortemente oversubscribed e il tempo CPU viene rubato dai vicini; ridurre la configurazione è l'unica soluzione per limitare i danni.
- Test del crollo della cache disco
dd if=/dev/zero of=/tmp/test bs=1M count=1024 conv=fdatasyncLa prima scrittura in cache è a 1.5GB/s, la seconda crolla a 150MB/s: la cache cede, tipico di uno storage condiviso oversubscribed. Vecchia configurazione + crollo del disco = doppia falsa specifica.
- Confronto con benchmark reale
curl -sL yabs.sh | bashIl punteggio single-core di Geekbench 5 è inferiore a 700, ma la frequenza dichiarata è 3.5GHz? Porta direttamente il report all'assistenza clienti e chiedi un rimborso o una migrazione in base alla differenza di prezzo con una nuova CPU a 4 core.
Infine, una regola ferrea: qualsiasi pagina promozionale che dichiari "alte prestazioni" ma non fornisca link a benchmark reali prima della vendita deve essere trattata come specifiche false. Fidati solo dei tuoi benchmark e paga il sovrapprezzo solo per una nuova CPU.
FAQ
Come riconoscere se la CPU del server cloud è obsoleta?
Usa il comando cat /proc/cpuinfo per vedere il modello e confronta l'anno di rilascio; poi monitora Steal Time: se steal è alto, c'è overselling e le CPU obsolete hanno prestazioni peggiori.
Come verificare le prestazioni reali con specifiche gonfiate?
Usa sysbench per testare la CPU e confronta con i punteggi di riferimento ufficiali; controlla anche la cache del disco e gli IOPS: i dischi invecchiati riducono i punteggi reali.