Rilevamento della banda di memoria sui server cloud: perché la velocità cala anche con capacità conforme

Avere capacità sufficiente non significa avere banda sufficiente: serve una perizia a tre dimensioni per vederci chiaro.

Aggiornato 2026-10-07 · CloudWorth

banda di memoriaSTREAMNUMArilevamento oversellingFinOpsCloudWorthSteal TimeOverselling VPSBenchmark VPS

Capacità conforme non equivale a banda conforme: usa STREAM insieme a Steal Time e al binding NUMA per una verifica incrociata, poi confronta il tasso di sovrapprezzo per decidere se fare upgrade o chiedere il rimborso.

Prima misura la capacità, poi la banda

Quando acquisti un server cloud, quasi tutti guardano per prima cosa la capacità di memoria: 8GB, 16GB, 32GB. La capacità è scritta nella pagina dell'ordine, è visibile e verificabile, quindi viene data per scontata come «memoria senza problemi». Ma la capacità è solo la superficie del magazzino, la banda è la velocità del carrello elevatore: un'istanza da 8GB può benissimo avere una capacità tutta verde e un throughput della memoria pari alla metà di quanto dichiarato per la stessa generazione.

Questo è lo scenario classico della capacità adeguata ma throughput in calo: carichi come inferenza AI, ricerca vettoriale, grandi value Redis, copie nell'heap JVM sono molto più sensibili ai GB/s che ai GB, e con capacità sufficiente si finisce prima contro il tetto della banda.

Separa prima i due aspetti:

1. Lato capacità: con free -h guarda total/available, poi confrontali con le specifiche dell'ordine e verifica che non ci siano recuperi nascosti da parte del driver balloon. Su KVM puoi controllare con dmesg | grep -i balloon.
2. Lato banda: che la capacità corrisponda non significa che la banda corrisponda; serve un test dedicato al throughput della memoria, che vedremo nella prossima sezione.

L'ordine deve essere prima capacità, poi banda. Se la capacità non è conforme, è una specifica falsa: vai direttamente al rimborso. Se la capacità è conforme ma la banda cala, allora è un problema più subdolo di overselling / throttling, e serve la catena di prove qui sotto.

Un criterio empirico: se acquisti un'istanza «stessa capacità ma a un prezzo chiaramente inferiore di una fascia», considera la banda sospetta per impostazione predefinita, invece di dare per scontato di aver fatto un affare. Questi affari spesso derivano da oversubscription della CPU, layout NUMA cross-node o declassamento della frequenza della memoria, e alla fine si ritorcono sotto forma di premio sul rapporto prezzo/prestazioni — hai comprato la capacità, non il throughput.

Dopo aver registrato i dati grezzi (specifiche dell'istanza, regione, immagine, tipo di fatturazione, ora dell'ordine), passa ai test reali. La registrazione stessa è la prova per i successivi ticket e per le decisioni di ridimensionamento; un ticket in cui si scrive solo «la memoria è lenta» quasi certamente non riceverà una gestione efficace.

Test pratici con STREAM e sysbench

Per il test della larghezza di banda della memoria esistono due strumenti complementari: STREAM misura il throughput vettoriale sostenibile (Copy/Scale/Add/Triad), sysbench memory misura scenari più vicini a «letture/scritture di piccoli blocchi».

La discussione sysbench vs STREAM memory bandwidth test for cloud servers non ha senso: vanno eseguiti entrambi, perché i loro tipi di distorsione sono diversi: STREAM è troppo generoso con la cache L3 delle istanze piccole, sysbench è troppo sensibile al costo delle istruzioni; solo incrociando i dati si evita di farsi ingannare da un singolo numero.

Uso di STREAM (compilabile nella home anche senza root):

sudo apt install -y gcc gfortran make
# 下载 stream.c 后：
gcc -O3 -fopenmp -DSTREAM_ARRAY_SIZE=200000000 stream.c -o stream
OMP_NUM_THREADS=$(nproc) ./stream

Impostare la dimensione dell'array a 1/4～1/2 della memoria: se è troppo piccola, tutto finisce nella cache e si ottiene una «larghezza di banda gonfiata»; altrimenti si misura la L3, non la DRAM.

Lato sysbench:

sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=read run
sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=write run

Ci sono tre punti chiave per la valutazione:

• Single-core vs tutti i core: eseguire rispettivamente taskset -c 0 e su tutti i core, registrando i GB/s. Se con tutti i core non aumenta quasi nulla, significa che la larghezza di banda è già limitata al massimo, non che manchino core.
• Confronto con i valori dichiarati: la differenza generazionale tra DDR4 e DDR5 è dell'ordine di 1,5～2 volte; tra istanze cloud della stessa generazione e stessa frequenza non dovrebbero esserci differenze di due o tre volte: se compaiono, sono un'anomalia.
• Conversione in larghezza di banda per vCPU: larghezza di banda totale / numero di vCPU è l'indicatore più pratico per valutare la sovravendita della larghezza di banda della memoria. Nelle istanze condivise la banda per vCPU è spesso solo la metà di quella delle istanze dedicate: è proprio una delle vere fonti della maggiorazione di prezzo dei server cloud.

Eseguire tre volte e prendere la mediana, evitando i picchi dei vicini allo scoccare dell'ora. Per convertire automaticamente questi numeri in larghezza di banda per vCPU e maggiorazione di prezzo, puoi creare un template in /app, inserendo insieme STREAM, sysbench e il prezzo dell'istanza, e generare un profilo di rapporto qualità-prezzo confrontabile. La prossima sezione userà Steal Time e NUMA per attribuire il «calo di prestazioni» a cause specifiche.

Analisi forense di Steal Time e NUMA

La sezione precedente può solo dimostrare che «la velocità è calata»; per l'attribuzione servono altri due indicatori: Steal Time e topologia NUMA. Questo è anche lo strato più facilmente saltato nel test della larghezza di banda della memoria di un server cloud: capacità sufficiente e anche una singola esecuzione supera lo standard, ma il collo di bottiglia si nasconde nello scheduling e nell'affinità di memoria. Le pagine delle specifiche nominali non riportano mai questi due elementi, e la differenza nei punteggi reali spesso deriva proprio da qui.

Iniziamo con st:

vmstat 1 10        # osserva la colonna st (Steal Time)
mpstat -P ALL 1    # %steal per core

Se st è stabilmente >3% e sincronizzato con il calo della larghezza di banda, significa che il tempo vCPU viene preso in prestito dai vicini. Su KVM condiviso la correlazione tra CPU steal e larghezza di banda della memoria è altissima: a calare è l'intero percorso, non solo la potenza di calcolo.

Ora guardiamo NUMA:

lscpu | grep -i numa
numactl --hardware
numactl --cpunodebind=0 --membind=0 \
  sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=read run

Se dopo aver vincolato il processo al nodo locale la larghezza di banda risale chiaramente, si tratta della penalità cross-node (comunemente 20%–40%), non di overselling; se anche dopo il binding si resta incollati al tetto di banda pro capite, allora è una vera limitazione.

Aprire un ticket con tre screenshot — st, topologia NUMA e larghezza di banda prima/dopo il binding — è molto più efficace che dire semplicemente «è diventato più lento». Se vuoi consolidarlo in un modello di analisi forense riutilizzabile, in /app puoi mettere insieme questi tre numeri e il prezzo unitario che paghi, calcolare il tasso di sovrapprezzo e poi decidere se aumentare le specifiche, cambiare zona di disponibilità o avviare la procedura di rimborso.

Verifica del precipizio della cache disco

Dopo il binding NUMA la larghezza di banda resta ancora incollata al tetto, manca un'ultima prova: usare il precipizio della cache per separare «memoria lenta» e «disco lento». Il metodo consiste nel leggere prima a caldo e poi a freddo lo stesso file, per vedere a quale dimensione del working set la larghezza di banda crolla.

# 1) 热路径：让 page cache 命中，测的是缓存速度
fio --name=hot --filename=/data/blob --rw=read --bs=1M \
    --size=4G --direct=0 --runtime=30 --time_based

# 2) 冷路径：清缓存后测真实内存→IO 通路
sync && echo 3 > /proc/sys/vm/drop_caches
fio --name=cold --filename=/data/blob --rw=read --bs=1M \
    --size=4G --direct=1 --runtime=30 --time_based

Punti chiave di lettura:

• La larghezza di banda in lettura a freddo, al crescere del working set da 256M a 4G, mostra una discesa graduale, che è il normale comportamento della gerarchia di memoria e del prefetch;
• Se invece precipita in un precipizio (ad esempio un dimezzamento netto intorno ai 2G), e il punto di rottura è molto inferiore alla L3/cache dichiarata dell'istanza, di solito indica che la larghezza di banda della memoria viene limitata, non che il disco sia il primo a cedere;
• Date anche un'occhiata a bi/bo e si/so in vmstat 1: se l'IO non è alto ma il throughput crolla di colpo, la colpa è quasi certamente dalla parte della memoria.

Questo è anche il punto in cui «benchmark reali vs configurazione dichiarata» è più facile che vada storto: un'istanza da 8GB con DDR4/DDR5 e capacità dichiarate non sbaglia nulla, ma appena la KV cache dell'inferenza AI o la ricerca vettoriale spingono il working set fuori dalla cache, la larghezza di banda cala per prima e la latenza inizia a oscillare. Mettete insieme il punto di precipizio, la larghezza di banda prima e dopo il binding NUMA, %steal e il prezzo unitario che pagate davvero per calcolare il tasso di sovrapprezzo, poi decidete se aumentare la configurazione, cambiare zona di disponibilità o richiedere il rimborso: è molto più efficace che riavviare ripetutamente. Se vi serve un modello di raccolta prove pronto all'uso, potete applicarlo direttamente in /app.

In una frase: raggiungere la capacità è solo il biglietto d'ingresso; il test della larghezza di banda della memoria di un server cloud deve guardare dove si trova il punto di svolta del rallentamento e a quale prezzo continui a pagare dopo quel punto.

Confronto dei benchmark e decisione sul sovrapprezzo

Nei passaggi precedenti abbiamo ottenuto tre set di dati concreti: Copy/Triad di STREAM, la differenza di larghezza di banda prima e dopo il binding NUMA e la curva %steal. Ora manca solo l'ultimo passo: allinearli alla fattura. Il metodo è semplice: scrivi su due colonne il «nominale vs misurato» della stessa istanza:

# 实测带宽（GB/s）
sysbench memory --memory-block-size=1M --memory-total-size=10G run | grep transferred
# 单价（元/GB 内存/月）= 月费 / 标称容量
# 性价比 = 实测带宽 / 单价

Le soglie di lettura possono essere approssimative, ma devono essere numeriche:

• La larghezza di banda misurata raggiunge oltre il 70% dei valori pubblici DDR4/DDR5 della stessa generazione, %steal normalmente sotto il 2%: condivisione normale, continua a usarla;
• La larghezza di banda è solo al 50%–70% di quanto nominalmente previsto, e il binding NUMA riesce a recuperare oltre il 15%: è un problema di scheduling, cambiare zona di disponibilità o specificare l'affinità vCPU spesso costa meno che aumentare le risorse;
• La larghezza di banda è inferiore al 50%, %steal è stabilmente sopra il 5% e il crollo della Cache compare in anticipo: questo è il tipico segnale di VPS overselling, una prova concreta di detect cloud server overselling.

Calcola il rapporto qualità-prezzo prima di parlare di azioni. Supponiamo che un'istanza da 8GB costi 120 yuan al mese e che la larghezza di banda misurata sia solo il 60% di quella di un'istanza AMD EPYC dello stesso prezzo: il tuo tasso di sovrapprezzo è in realtà del 40%. A questo punto passare a 16GB spesso non fa altro che amplificare il «più caro per GB»; cambiare tipo di istanza o chiedere il rimborso è più conveniente. Calcola il tasso di sovrapprezzo prima di fare l'upgrade e raccogli le prove prima di chiedere il rimborso: invia insieme l'output grezzo dei tre benchmark, %steal da vmstat e lo screenshot di numactl --hardware; nel ticket scrivi solo i dati e non gli aggettivi, e la probabilità di ribaltare la decisione sarà molto più alta. Esegui gli stessi test anche prima del rinnovo, per evitare che il rinnovo riduca di nascosto le risorse. La tabella completa per la raccolta delle prove e il modello di ticket sono in /guides/memory-bandwidth-checklist; puoi copiarli direttamente.

Ricorda la conclusione: capacità adeguata non significa larghezza di banda adeguata; usa STREAM insieme a Steal Time e binding NUMA per una verifica incrociata, poi confronta il tasso di sovrapprezzo per decidere se fare l'upgrade o chiedere il rimborso.