Speicherbandbreite von Cloud-Servern messen: Warum die Leistung trotz erreichter Kapazität einbricht

Genug Kapazität heißt nicht genug Bandbreite – erst die dreidimensionale Forensik schafft Klarheit.

Aktualisiert 2026-10-07 · CloudWorth

SpeicherbandbreiteSTREAMNUMAÜberverkauf-ErkennungFinOpsCloudWorthSteal TimeVPS OversellingVPS Benchmark

Erreichte Kapazität bedeutet nicht erreichte Bandbreite. Mit STREAM, Steal Time und NUMA-Pinning kreuzweise belegen und dann anhand der Preisprämie entscheiden, ob ein Upgrade oder eine Rückerstattung fällig ist.

Erst Kapazität messen, dann Bandbreite

Beim Kauf eines Cloud-Servers ist für fast alle der erste Blick die RAM-Kapazität: 8 GB, 16 GB, 32 GB. Die Kapazität steht auf der Bestellseite, ist sichtbar, stimmt überein, und wird daher standardmäßig als „RAM ist in Ordnung“ angenommen. Doch Kapazität ist nur die Lagerfläche, Bandbreite ist die Gabelstapler-Geschwindigkeit – eine 8-GB-Instanz kann bei vollständig grüner Kapazität durchaus nur die Hälfte des nominellen Speicherdurchsatzes derselben Generation erreichen.

Das ist das klassische Szenario von Kapazität erfüllt, aber Geschwindigkeit bricht ein: Workloads wie AI-Inferenz, Vektorsuche, große Redis-Values, JVM-Heap-internes Kopieren reagieren weit empfindlicher auf GB/s als auf GB; ausreichende Kapazität stößt dann zuerst an die Bandbreiten-Obergrenze.

Zunächst zwei Schritte trennen:

1. Kapazitätsseite: Mit free -h total/available prüfen, dann gegen die Bestellspezifikation abgleichen und sicherstellen, dass kein versteckter Balloon-Treiber Speicher zurückgeholt hat. Unter KVM kann man dmesg | grep -i balloon prüfen.
2. Bandbreitenseite: Dass die Kapazität stimmt, heißt nicht, dass die Bandbreite stimmt; dafür braucht es einen speziellen Speicherdurchsatztest, der im nächsten Abschnitt erläutert wird.

Die Reihenfolge muss erst Kapazität, dann Bandbreite sein. Wenn die Kapazität nicht stimmt, ist es eine Falschangabe, und man geht direkt auf Rückerstattung; wenn die Kapazität stimmt, aber die Bandbreite einbricht, ist das das verstecktere Problem von Überverkauf / Drosselung, das die folgende Beweiskette erfordert.

Eine Faustregel: Wenn du eine Instanz mit „gleicher Kapazität, aber deutlich niedrigerer Preisklasse“ kaufst, gehe zunächst davon aus, dass die Bandbreite verdächtig ist, statt anzunehmen, du hast ein Schnäppchen gemacht. Solche Schnäppchen stammen oft von CPU-Overcommit, NUMA-knotenübergreifendem Layout oder heruntergetakteter Speicherfrequenz und rächen sich am Ende in Form eines Preis-Leistungs-Aufschlags – Kapazität gekauft, Durchsatz nicht bekommen.

Nachdem die Rohdaten dokumentiert wurden (Instanzspezifikation, Region, Image, Abrechnungsart, Bestellzeitpunkt), geht es in die Messung. Die Aufzeichnung selbst ist der Beweis für spätere Support-Tickets und Downgrade-Entscheidungen; ein Ticket, in dem nur „der Speicher ist langsam“ steht, wird fast nie effektiv bearbeitet.

STREAM- und sysbench-Messungen in der Praxis

Für die Messung der Speicherbandbreite gibt es zwei komplementäre Werkzeuge: STREAM misst den nachhaltigen Vektor-Durchsatz (Copy/Scale/Add/Triad), sysbench memory misst Szenarien, die eher „kleinen Block-Lese-/Schreibvorgängen“ entsprechen. Die Debatte sysbench vs STREAM memory bandwidth test for cloud servers ist sinnlos, beide müssen ausgeführt werden, denn ihre Verzerrungsrichtungen unterscheiden sich: STREAM ist zu freundlich zum L3-Cache kleiner Instanzen, sysbench ist zu empfindlich gegenüber Instruktions-Overhead; nur im Kreuzvergleich lässt man sich nicht von einem einzelnen Zahlenwert täuschen.

STREAM-Verwendung (Kompilierung ins Home-Verzeichnis auch ohne root möglich):

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

Die Array-Größe sollte auf 1/4 bis 1/2 des Arbeitsspeichers gesetzt werden; ist sie zu klein, landet alles im Cache und man erhält „künstlich hohe Bandbreite“; andernfalls misst man L3 statt DRAM.

Bei 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

Es gibt drei entscheidende Kriterien:

• Einzelkern vs. alle Kerne: Führen Sie taskset -c 0 und alle Kerne getrennt aus und notieren Sie GB/s. Wenn bei allen Kernen kaum ein Anstieg zu verzeichnen ist, bedeutet das, dass die Bandbreite bereits limitiert ist und nicht die Kernanzahl unzureichend ist.
• Vergleich mit den Spezifikationen: Der Generationsunterschied zwischen DDR4 und DDR5 liegt in der Größenordnung von etwa 1,5 bis 2 Mal; bei Cloud-Instanzen derselben Generation und Frequenz sollte kein zwei- bis dreifacher Unterschied auftreten – tritt er auf, ist das eine Anomalie.
• Umrechnung in Bandbreite pro vCPU: Gesamtbandbreite / Anzahl vCPUs ist die praktischste Kennzahl zur Beurteilung von Speicherbandbreiten-Überbuchung. Bei Shared-Instanzen liegt die Bandbreite pro vCPU oft nur bei der Hälfte von Dedicated-Instanzen – genau das ist eine der tatsächlichen Quellen für den Cloud-Server-Preisaufschlag.

Führen Sie drei Durchläufe aus und nehmen Sie den Median, und vermeiden Sie Spitzenlasten durch Nachbarn zur vollen Stunde. Wenn Sie diese Zahlen automatisch in Bandbreite pro vCPU und Preisaufschlag umrechnen möchten, können Sie in /app eine Vorlage erstellen, STREAM, sysbench und den Instanzpreis gemeinsam eingeben und ein vergleichbares Preis-Leistungs-Profil generieren. Im nächsten Abschnitt wird mithilfe von Steal Time und NUMA der „Geschwindigkeitseinbruch“ auf konkrete Ursachen zurückgeführt.

Forensik mit Steal Time und NUMA

Der vorige Abschnitt kann nur belegen, dass die Geschwindigkeit eingebrochen ist; die Ursachenzuordnung erfordert zwei weitere Metriken: Steal Time und NUMA-Topologie. Das ist zugleich die am leichtesten übersehene Ebene bei der Speicherbandbreitenmessung von Cloud-Servern – die Kapazität reicht, ein einzelner Lauf erfüllt ebenfalls den Zielwert, doch der Engpass versteckt sich in Scheduling und Speicher-Affinität. Auf nominellen Konfigurationsseiten werden diese beiden Punkte nie erwähnt; die Unterschiede bei echten Benchmarks rühren oft genau daher.

Zuerst ein Blick auf st:

vmstat 1 10        # 盯 st 列（Steal Time）
mpstat -P ALL 1    # 逐核 %steal

Wenn st dauerhaft >3 % liegt und synchron mit dem Bandbreitenrückgang auftritt, bedeutet das, dass vCPU-Zeit gerade von Nachbarn ausgeliehen wird. Bei Shared-KVM ist die Korrelation zwischen CPU-Steal und Speicherbandbreite extrem hoch; es bricht der gesamte Pfad ein, nicht nur die Rechenleistung.

Nun zu 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

Wenn die Bandbreite nach dem Binden des Prozesses an den lokalen Knoten deutlich wieder ansteigt, handelt es sich um eine Cross-Node-Strafe (häufig 20 %–40 %), nicht um Overselling; wenn sie auch nach dem Binden noch am Pro-Kopf-Bandbreitenlimit klebt, ist es tatsächlich eine echte Drosselung.

Mit drei Screenshots – st, NUMA-Topologie und Bandbreite vor/nach dem Binden – ein Ticket zu eröffnen, ist deutlich effektiver, als nur zu sagen, es sei „langsamer geworden“. Wenn du daraus eine wiederverwendbare Forensik-Vorlage machen willst, kannst du in /app diese drei Werte zusammen mit dem von dir gezahlten Stückpreis ablegen, die Aufschlagsrate sauber berechnen und dann entscheiden, ob du aufrüstest, die Availability Zone wechselst oder ein Rückerstattungsverfahren einleitest.

Verifikation der Disk-Cache-Klippe

Nach NUMA-Bindung klebt die Bandbreite weiter am Maximum; es fehlt nur noch der letzte Beweis: Mit einer Cache-Klippe lassen sich „langsamer Speicher“ und „langsame Platte“ voneinander trennen. Dazu liest man dieselbe Datei erst heiß und dann kalt und beobachtet, bei welcher Working-Set-Größe die Bandbreite einbricht.

# 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

Beurteilungspunkte:

• Die Kaltlese-Bandbreite nimmt mit steigendem Working Set von 256M auf 4G glatt ab; das ist normales Verhalten der Speicherhierarchie und des Prefetchings;
• Fällt sie dagegen als Klippe ab (z. B. um 2G herum direkt auf die Hälfte), und liegt der Knick weit unter dem für die Instanz angegebenen L3/Cache-Erwartungswert, deutet das meist auf gedrosselte Speicherbandbreite hin und nicht darauf, dass zuerst die Platte nicht mehr mithält;
• Wirf außerdem einen Blick auf bi/bo und si/so in vmstat 1; wenn die IO nicht hoch ist, der Durchsatz aber plötzlich einbricht, liegt die Ursache grundsätzlich auf der Speicherseite.

Genau hier kippt „echter Benchmark vs. nominelle Konfiguration“ am häufigsten: Bei einer 8-GB-Instanz stimmen DDR4/DDR5 und Kapazität nominell, aber sobald der KV-Cache einer KI-Inferenz oder eine Vektorsuche das Working Set aus dem Cache drückt, sinkt zuerst die Bandbreite, und die Latenz beginnt unmittelbar zu schwanken. Setzt man den Klippenpunkt, die Bandbreite vor und nach der NUMA-Bindung und %steal zusammen mit dem tatsächlich gezahlten Stückpreis in eine Rechnung und ermittelt die Prämienrate, bevor man über Upgrade, Availability-Zone-Wechsel oder Refund entscheidet, ist das deutlich wirksamer als wiederholtes Neustarten. Wer eine fertige Beweissicherungsvorlage braucht, kann sie in /app direkt verwenden.

Ein Satz: Erfüllte Kapazität ist nur die Eintrittskarte; bei der Prüfung der Speicherbandbreite von Cloud-Servern kommt es darauf an, wo der Knickpunkt des Geschwindigkeitsabfalls liegt – und zu welchem Preis du danach noch bezahlst.

Benchmark-Abgleich und Entscheidung zum Preisaufschlag

In den vorherigen Abschnitten haben wir bereits drei harte Datenpunkte erhalten: die Copy-/Triad-Werte von STREAM, die Bandbreitendifferenz vor und nach NUMA-Bindung sowie die %steal-Kurve. Jetzt fehlt nur noch der letzte Schritt – sie mit der Rechnung abzugleichen. Das Vorgehen ist einfach: Schreiben Sie für dieselbe Instanz „nominal vs. gemessen“ in zwei Spalten:

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

Die Beurteilungsgrenzen dürfen grob sein, müssen aber mit Zahlen belegt werden:

• Die gemessene Bandbreite erreicht über 70 % der öffentlichen Werte der gleichen DDR4-/DDR5-Generation, und %steal liegt normalerweise unter 2 %: normale gemeinsame Nutzung, weiter verwenden;
• Die Bandbreite liegt nur bei 50–70 % des nominell erwarteten Werts, und NUMA-Bindung kann 15 % oder mehr zurückholen: Das ist ein Scheduling-Problem; ein Wechsel der Verfügbarkeitszone oder die Festlegung der vCPU-Affinität ist oft billiger als ein Upgrade;
• Die Bandbreite liegt unter 50 %, %steal dauerhaft über 5 %, und der Cache-Einbruch tritt vorzeitig auf: Das ist ein typisches Signal für VPS-Überverkauf und ein klarer Beweis für das Aufdecken von Cloud-Server-Überverkauf.

Berechnen Sie erst das Preis-Leistungs-Verhältnis, bevor Sie über Maßnahmen sprechen. Angenommen, eine 8-GB-Instanz kostet 120 Yuan pro Monat und die gemessene Bandbreite beträgt nur 60 % einer AMD-EPYC-Instanz im selben Preisbereich, dann liegt Ihre Aufpreisquote tatsächlich bei 40 % – ein Upgrade auf 16 GB verstärkt dann oft nur das „pro GB teurer“, und ein Wechsel des Instanztyps oder eine Rückerstattung ist wirtschaftlicher. Berechnen Sie vor einem Upgrade die Aufpreisquote, und sichern Sie vor einer Rückerstattung die Beweise: Reichen Sie die Rohausgaben von drei Benchmark-Läufen, %steal aus vmstat und einen Screenshot von numactl --hardware zusammen ein; schreiben Sie in das Ticket nur Daten und keine Adjektive – dann ist die Chance auf eine erfolgreiche Anfechtung viel höher. Führen Sie vor der Verlängerung dieselbe Messung erneut durch, um zu verhindern, dass bei der Verlängerung heimlich die Leistung reduziert wird. Die vollständige Beweistabelle und Ticketvorlage finden Sie unter /guides/memory-bandwidth-checklist; Sie können sie direkt übernehmen.

Denken Sie an die Schlussfolgerung: Erfüllte Kapazität bedeutet nicht erfüllte Bandbreite. Nutzen Sie STREAM sowie Steal Time und NUMA-Bindung zur Gegenprüfung und entscheiden Sie anhand der Aufpreisquote, ob Sie aufstocken oder eine Rückerstattung verlangen.