Hoe meet je de geheugenbandbreedte van een cloudserver? Oververkoop en valse specificaties doorzien

Doorzie valse geheugenbandbreedte-specificaties met de kruisauditmethode

Bijgewerkt 2026-08-12 · CloudWorth

geheugenbandbreedtebenchmarktestoververkoopdetectieFinOpsCloudWorthSteal TimeVPS oversellingVPS benchmark

Bij geheugenbandbreedtetests moet u rekening houden met Steal Time en cache-afgrond, en de FinOps-premie gebruiken om de echte prijs-kwaliteitverhouding te bepalen.

Benchmarkmethode: STREAM en mbw

Voor het testen van geheugenbandbreedte van cloudservers gebruik ik het liefst twee tools: STREAM en mbw. STREAM benadert de theoretische piek en is geschikt om de hardwaregeneratie te beoordelen; mbw ligt dichter bij de werkelijke lees-/schrijfdruk en is vooral geschikt voor Docker/K8s-containeromgevingen. De commando's zijn eenvoudig:

# STREAM（需编译）
gcc -O3 -fopenmp stream.c -o stream
./stream

# mbw（apt/yum均可装）
mbw -n 8 512

Maar trek niet te snel conclusies uit de cijfers. De valkuil bij het testen van geheugenbandbreedte van cloudservers zit juist in de virtualisatielaag. Kijk voordat je begint eerst naar de steal time in /proc/stat. Als bij opeenvolgende metingen de steal time meer dan 2% bedraagt, betekent dit dat de fysieke CPU door een buurman wordt opgeëist; de gemeten bandbreedte zal dan duidelijk lager zijn. Kijk vervolgens naar de cache-klif: vergroot de testarray stap voor stap. Als de bandbreedte op een bepaald punt plotseling tot onder een derde zakt, is het zeer waarschijnlijk dat de L3-cache wordt beperkt of dat er concurrentie om is.

Nu het belangrijkste punt: hoeveel mogen de nominale en gemeten waarde van elkaar afwijken voordat je van misleidende specificaties kunt spreken? Ik reken de geheugenbandbreedte gewoonlijk om naar de 'prijs per GiB' en vergelijk die met de referentiewaarde van een bare metal-server met dezelfde configuratie, om zo de FinOps-premie te berekenen. Als de premie meer dan 30% is, maar de bandbreedte slechts de helft van de theoretische waarde bereikt, kan men dat in wezen karakteriseren als overboeking of generatiekrimp. Dat is de aanpak van CloudWorth cross-audit: benchmarken in realistische scenario's om de prijs-kwaliteitverhouding vast te stellen. Het volledige vergelijkingssjabloon vind je verderop in deze gids. Onthoud eerst één principe: benchmarken is geen doel, maar het identificeren van het 'prijs-kwaliteit-omslagpunt'.

Valse specificaties herkennen: Steal Time en Cache

Wees niet te snel blij met mooie cijfers van STREAM of mbw. Het meest verraderlijke aan cloudservers is niet dat individuele bandbreedte laag is, maar dat het er hoog uitziet en instort zodra je er druk op zet. Ik test gewoonlijk drie dingen kruislings: geheugenbandbreedte, Steal Time en cache-hitrate. Vooral na het draaien van mbw kijk ik naar steal in /proc/stat. Als dit consistent boven de 10% ligt, duidt dat op ernstige CPU-overprovisioning op de host. De 'vCPU' die je hebt gekocht, deelt mogelijk kernen met buren, en de geheugenbandbreedte-testresultaten worden gemaskeerd door opgeblazen waarden of schommelingen.

De echte boosdoener is een cache-afgrond. Gebruik stream om verschillende arraygroottes te testen. Als de bandbreedte met meer dan 60% daalt bij de overgang van 8MB naar 16MB, kun je er vrijwel zeker van zijn dat de L3-cache is opgedeeld of dat de instantie is gedegradeerd naar een oudere CPU-generatie. Neem bijvoorbeeld een beursgenoteerd bedrijf dat 'high-frequency geheugen' adverteert, maar in de praktijk presteert het slechter dan hun eigen instapmodel. In zo'n geval moet je de prijspremieformule van CloudWorth gebruiken: (werkelijke prestaties / nominale prestaties) ÷ (prijs / gemiddelde prijs in dezelfde categorie). Als dit onder 0,7 ligt, kun je het beter meteen retourneren.

Bij testen in containers is voorzichtigheid geboden: Docker deelt standaard de kernel, en mbw wordt beïnvloed door cgroup-limieten. Het is beter om --cpuset-mems toe te voegen om aan NUMA-knooppunten te binden voordat je test; anders zijn de resultaten slechts voor de lol. Als je echt AI-inferentiescenario's wilt reproduceren, kun je het beste direct met pytorch een mini-batch matrixvermenigvuldiging draaien en vergelijken met de fysieke machine-baseline. Dat is betrouwbaarder dan welke benchmarktool dan ook.

FinOps-premieratio: echte prijs/kwaliteit

Bij het testen van de geheugenbandbreedte van cloudservers is het grootste probleem niet dat je verkeerd meet, maar dat je na het meten niet weet hoe je de rekening moet opmaken. De Steal Time en de cache-klif uit de vorige twee secties beantwoorden in wezen dezelfde vraag: koop je met je geld de “gespecificeerde configuratie” of de “erechte rekenkracht”? Nu combineer ik deze twee indicatoren met de bandbreedtetestresultaten en bereken ik voor elke instantie een “FinOps-premieratio” – de formule is eenvoudig: premieratio = gemeten bandbreedte ÷ nominale theoretische bandbreedte ÷ eenheidsprijs. Hoe hoger de verhouding, hoe reëler de bandbreedte die je voor je investering terugkrijgt; omgekeerd heb je te maken met typische “opgeblazen configuratie”.

Neem het voorbeeld van een cloudprovider die net naar de beurs is gegaan, waarvan het aandeel op één dag met 42% steeg en die vervolgens zijn excuses aanbood: nominaal 8 kernen, 16G, theoretische geheugenbandbreedte ongeveer 40 GB/s (schatting op basis van DDR4 dual-channel). Met mbw in de vaste modus meet je slechts 17 GB/s, vergezeld van 5% Steal Time, en de cache-klif verschijnt op 4 MB (in plaats van de verwachte 16 MB L3-cache). Op hetzelfde moment biedt een andere gevestigde cloudprovider een instantie met dezelfde configuratie aan voor 18% meer, maar de gemeten bandbreedte haalt 32 GB/s en de Steal Time is vrijwel nul. De premieratio van de eerste is slechts 0,43, die van de laatste 0,81 – het goedkopere exemplaar is in feite de “duurdere”.

En dat is nog niet alles. Toen ik de test naar de containeromgeving verplaatste en STREAM in Docker uitvoerde, merkte ik dat de CPU-quota van cgroup stilletjes de geheugenbandbreedte beperken, vooral in multicore-scenario’s kan het mbw-resultaat kunstmatig hoog uitvallen. Daarom geldt in mijn kruisauditmethode: bij alle bandbreedtetests moet je zowel de tijd binnen als buiten de container registreren en vervolgens normaliseren met de FinOps-premieratio. Zo zijn zowel KVM als Xen, met of zonder oversubscription, naar een vergelijkbare prijsdimensie te brengen.

Tot slot nog een laatste waarschuwing: geloof niet blind in “realtime facturering” of “elastic scaling”, dat is slechts de vriendelijkheid op de factuur. De echte prijs/kwaliteit krijg je door mbw -b 256 te draaien, het cache-klif-rapport van CloudWorth erbij te pakken, de respectievelijke premieratio’s te berekenen en dan die “goedkope” machine uit te schakelen. Geheugenbandbreedte liegt niet, de factuur doet dat wel.