Wie misst man die Speicherbandbreite eines Cloud-Servers? Überbuchung und Übertreibungen erkennen

Mit der Kreuzprüfung Speicherbandbreiten-Übertreibungen entlarven

Aktualisiert 2026-08-12 · CloudWorth

SpeicherbandbreiteBenchmark-TestÜberbuchungserkennungFinOpsCloudWorthSteal TimeVPS OversellingVPS Benchmark

Beim Test der Speicherbandbreite sollten Steal Time und Cache-Einbruch kombiniert werden, um mit der FinOps-Prämie das tatsächliche Preis-Leistungs-Verhältnis zu ermitteln.

Benchmark-Methode: STREAM und mbw

Für die Prüfung der Speicherbandbreite von Cloud-Servern verwende ich am häufigsten zwei Tools: STREAM und mbw. STREAM tendiert zum theoretischen Spitzenwert und eignet sich gut, um Hardware-Generationen zu beurteilen; mbw liegt näher an der realen Lese-/Schreiblast und ist besonders für Docker/K8s-Containerumgebungen geeignet. Die Befehle sind einfach:

# STREAM (muss kompiliert werden)
gcc -O3 -fopenmp stream.c -o stream
./stream

# mbw (mit apt/yum installierbar)
mbw -n 8 512

Aber ziehen Sie nicht voreilig Schlüsse aus den Zahlen. Die Fallstricke beim Testen der Speicherbandbreite von Cloud-Servern liegen genau in der Virtualisierungsschicht. Bevor Sie starten, werfen Sie einen Blick auf die steal time in /proc/stat. Wenn die kontinuierliche Abtastung über 2 % liegt, bedeutet das, dass die physische CPU vom Nachbarn beansprucht wird – die gemessene Bandbreite ist dann deutlich zu niedrig. Beachten Sie außerdem den cache-Abfall: Vergrößern Sie das Testarray schrittweise. Wenn die Bandbreite an einem bestimmten Punkt plötzlich auf unter ein Drittel fällt, ist wahrscheinlich der L3-Cache begrenzt oder umkämpft.

Jetzt kommt der wichtigste Punkt: Wie groß muss die Abweichung zwischen Nennwert und Messwert sein, um als übertrieben zu gelten? Ich rechne die Speicherbandbreite normalerweise in einen „Preis pro GiB“ um, vergleiche sie mit den Referenzwerten vergleichbarer Bare-Metal-Konfigurationen und berechne so die FinOps-Prämie. Wenn die Prämie über 30 % liegt, die Bandbreite aber nur die Hälfte des theoretischen Werts beträgt, kann man das im Grunde als Überverkauf oder Generationsschrumpfung einstufen. Genau das ist der Ansatz der CloudWorth-Kreuzprüfung – Mit realen Szenarien das Preis-Leistungs-Verhältnis ermitteln. Die vollständige Vergleichsvorlage habe ich in den späteren Lesezeichen abgelegt. Merken Sie sich zunächst ein Prinzip: Das Ziel ist nicht das Benchmarking, sondern das Erkennen des „Preis-Leistungs-Knickpunkts“.

Erkennen von übertriebenen Werten: Steal Time und Cache

Freue dich nicht zu früh über schöne Zahlen von STREAM oder mbw. Bei Cloud-Servern ist nicht die geringe Einzelbandbreite das Ärgste, sondern „sieht hoch aus, bricht unter Druck zusammen“. Ich pflege drei Dinge quer zu testen: Speicherbandbreite, Steal Time, Cache-Trefferquote. Besonders nachdem mbw durchgelaufen ist, schaue ich mir den Steal-Wert in /proc/stat an. Wenn er dauerhaft über 10% liegt, ist der Host-CPU massiv überbucht. Deine gekauften „vCPUs“ konkurrieren womöglich mit Nachbarn um Kerne, und die Ergebnisse des Speicherbandbreitentests werden durch übertriebene Werte oder Schwankungen verdeckt.

Der wahre Killer ist der Cache-Abbruch. Wenn man mit stream verschiedene Array-Größen testet und die Bandbreite beim Sprung von 8 MB auf 16 MB um mehr als 60% einbricht, kann man im Grunde davon ausgehen, dass der L3-Cache aufgeteilt wurde oder die Instanz auf eine alte CPU-Generation herabgestuft wurde. Wenn zum Beispiel ein IPO-Unternehmen „Speicher mit hoher Taktfrequenz“ bewirbt, das tatsächlich schlechter abschneidet als seine eigene Einstiegsklasse, muss man mit der CloudWorth-Aufschlagsformel rechnen: (tatsächliche Leistung / Nennleistung) ÷ (Preis / Durchschnittspreis vergleichbarer Produkte), und wenn das unter 0,7 liegt, sollte man es entschieden zurückgeben.

Beim Testen im Container ist Vorsicht geboten: Docker teilt standardmäßig den Kernel, mbw wird durch cgroup-Limits beeinflusst. Am besten fügt man --cpuset-mems hinzu, um NUMA-Knoten zu binden, und testet dann erneut, sonst kann man das Ergebnis nur als Unterhaltung betrachten. Um ein reales KI-Inferenz-Szenario zu reproduzieren, empfiehlt es sich, direkt mit pytorch eine Mini-Batch-Matrixmultiplikation auszuführen und mit einer physischen Maschinen-Basislinie zu vergleichen. Das ist praktischer als jedes Benchmark-Tool.

FinOps-Prämienrate: Echtes Preis-Leistungs-Verhältnis

Bei der Prüfung der Speicherbandbreite von Cloud-Servern ist die größte Angst nicht, falsch zu messen, sondern dass man nach dem Messen nicht weiß, wie man die Rechnung aufmacht. Die Abschnitte zu Steal Time und Cache-Einbruch in den vorherigen beiden Teilen beantworten im Wesentlichen dieselbe Frage: Kauft man mit seinem Geld die „Nennkonfiguration“ oder die „tatsächliche Rechenleistung“? Nun kombiniere ich diese beiden Kennzahlen mit den Bandbreitentestergebnissen und berechne für jede Instanz eine „FinOps-Prämienrate“ – die Formel ist einfach: Prämienrate = gemessene Bandbreite ÷ theoretische Nennbandbreite ÷ Einheitspreis. Je höher der Wert, desto substanzieller ist die Bandbreite, die man pro investierter Einheit zurückbekommt; im Umkehrschluss handelt es sich um eine typische „aufgeblähte Konfiguration“.

Nehmen wir als Beispiel eine Cloud-Instanz, die gerade an die Börse gegangen ist, deren Aktienkurs an einem Tag um 42 % gestiegen ist und die sich anschließend entschuldigt hat: nominell 8 Kerne, 16 GB, mit einer theoretischen Speicherbandbreite von etwa 40 GB/s (DDR4-Dual-Channel-Schätzung). Mit mbw im Fixed-Modus gemessen, kommen nur 17 GB/s heraus, begleitet von 5 % Steal Time; der Cache-Einbruch erscheint bei 4 MB (statt der erwarteten 16 MB L3). Gleichzeitig verlangt ein anderes etabliertes Cloud-Unternehmen für eine Instanz mit derselben Konfiguration 18 % mehr, aber die gemessene Bandbreite erreicht 32 GB/s, und die Steal Time liegt bei fast 0. Rechnet man es aus, beträgt die Prämienrate der ersteren nur 0,43, die der letzteren 0,81 – die billigere Maschine ist in Wahrheit die „teurere“.

Das ist noch nicht alles. Als ich die Tests in die Container-Umgebung verlagere und STREAM in Docker ausführe, stelle ich fest, dass die cgroup-CPU-Kontingente die Speicherbandbreite heimlich begrenzen, insbesondere bei Mehrkern-Szenarien können mbw-Ergebnisse zu hoch ausfallen. Daher verwende ich in meiner Kreuzprüfungsmethode bei allen Bandbreitentests sowohl die Zeit innerhalb als auch außerhalb des Containers, und normalisiere sie dann mit der FinOps-Prämienrate. So lassen sich sowohl KVM als auch Xen und sowohl überbuchte als auch nicht überbuchte Systeme auf eine vergleichbare Preisdimension bringen.

Zum Schluss noch eine Spitze: Verlass dich nicht auf „Echtzeit-Abrechnung“ oder „automatische Skalierung“ – das ist nur die Freundlichkeit auf der Rechnung. Das wahre Preis-Leistungs-Verhältnis findest du heraus, indem du mbw -b 256 ausführst, den Cache-Einbruch-Bericht von CloudWorth vergleichst, die jeweiligen Prämienraten berechnest und dann die „billige“ Maschine abschaltest. Speicherbandbreite lügt nicht, die Rechnung schon.