Cloud-Server-Benchmarks und übertriebene Spezifikationen: Erkennung und Vermeidung alter CPUs

Dreifache Beweisführung entlarvt die Lüge vom Aufpreis für alte CPUs

Aktualisiert 2026-08-25 · CloudWorth

BenchmarksÜbertriebene SpezifikationenSteal TimeÜberverkaufPreis-Leistungs-VerhältnisCloudWorthVPS OversellingVPS Benchmark

Mit Steal Time + Disk-Cache + echten Benchmarks dreifach verifizieren und sich weigern, einen Aufpreis für alte CPUs zu zahlen.

Wie weit die echte Leistung von der Nennleistung abweicht

Die Diskrepanz zwischen den Benchmark-Ergebnissen von Cloud-Servern und der angegebenen Konfiguration ist oft größer als erwartet. Vor allem einige ältere CPUs, die mit „hoher Taktrate“ werben, wie die Xeon-Modelle E5-2690 v4 und E5-2680 v4 aus der Zeit um 2016, haben auf dem Papier eine ordentliche Single-Core-Frequenz, aber in der Praxis kann das Single-Thread-Benchmark-Ergebnis nur halb so hoch sein wie bei neueren Xeon-Generationen. Es gibt zwei Hauptursachen für diese „übertriebenen“ Benchmarks: zum einen die Unterschiede zwischen Hardware-Generationen, zum anderen ein drastisch ansteigender Steal Time aufgrund von Überbelegung.

Bei älteren Plattformen mit Virtualisierung zeigt das Feld steal in /proc/stat an, wie viel CPU-Zeit der Hypervisor entzogen hat. Wenn mpstat -P ALL 1 über einen längeren Zeitraum einen %steal von über 10% anzeigt, bedeutet das, dass Nachbarn mit dir um Ressourcen konkurrieren. In diesem Fall sind die Benchmarks unabhängig von der Nennleistung instabil. Ein weiterer subtiler Indikator ist der Cache-Abbruch bei der Festplatte – bei alten CPUs mit altem Speicher halbiert sich die IOPS nach Erschöpfung des Caches direkt, und die Benchmark-Kurve weist einen deutlichen Einbruch auf.

Um die Abweichung zu quantifizieren, kannst du yabs oder sysbench cpu --threads=1 run ausführen und mit den offiziellen Angaben vergleichen. Ich bin auf eine ältere Plattform mit einer Nennfrequenz von 3,5 GHz gestoßen, deren tatsächliches Single-Core-Benchmark um 40% niedriger war als das einer neuen Plattform mit 2,9 GHz. Das bedeutet, dass die Hälfte des Geldes, das du für „hohe Taktrate + alte Konfiguration“ zahlst, möglicherweise nur ein Aufpreis für gebrauchte Hardware ist. Genau das ist der typischste negative Kostenfaktor im FinOps: Mit dem gleichen Budget sind die Kosten pro Recheneinheit niedriger, wenn du eine neue Plattform oder offiziell zertifizierte Instanzen wählst.

Also, schau nicht nur auf die Nennparameter. Es wird empfohlen, auf CloudWorth Instanzen nach tatsächlicher Benchmark-Leistung und Steal-Time-Schwellenwert zu filtern und dein Budget in echte Leistung zu investieren.

Steal Time – Überverkauf aufdecken

Um die übertriebenen Angaben zur Cloud-Server-Konfiguration zu durchschauen, schneiden wir zuerst beim steal time an. Diese Kennzahl ist das Codewort des Hypervisors: Wenn die physische CPU vom Vermieter an die benachbarte VM vergeben wird, muss deine vCPU warten. Nutze top, drücke C, um zur CPU-Liste zu wechseln, dann t, um die Steal-Spalte zu sehen, oder führe direkt vmstat 1 aus und beobachte das Feld st. Sample einige Minuten lang: Wenn der st-Durchschnitt über 5 % liegt oder sogar Spitzen von 20 %+ auftreten, herzlichen Glückwunsch – du teilst dir denselben physischen Kern mit einer Gruppe übler Nachbarn.

# 连续采样 10 次，每次间隔 1 秒，取 st 平均值
vmstat 1 10 | awk 'NR>3 {sum+=$16} END {print "avg steal:", sum/(NR-3), "%"}'

Steal-Time-Spitzen sind alarmierender als ein stabiler hoher Wert – sie zeigen, dass der Überverkauf dynamisch ist. In Spitzenzeiten wird deine Antwortzeit zufällig wie ein EKG schwanken. In Kombination mit dem in der letzten Sektion erwähnten Abfall bei der Festplatten-Cache kann man damit praktisch bestätigen, dass es sich um einen Host handelt, der auf einer alten physischen Maschine immer wieder untervermietet wird.

Aus FinOps-Perspektive ist dies ein typischer Aufpreisbetrug: Du zahlst den Preis für neue Hardware, bekommst aber nur die Überreste einer alten CPU, die in Stücke geschnitten wurde – der Aufschlag erreicht fast das Dreifache der Public Cloud. Vertraue nicht blind auf hohe Taktraten: Egal wie stark ein alter Xeon-Kern ist, er hält dem Vorpreschen der Nachbarn nicht stand. Schau dir vor dem Benchmarking den Steal an, sonst sind die Geekbench-Zahlen noch so schön – nur eine Fata Morgana auf dem Sandkasten des Überverkaufs. Diese Kennzahl ist kostenlos, reproduzierbar und ehrlicher als jedes Versprechen eines Anbieters.

Beweissicherung für den Disk-Cache-Einbruch

Zuvor haben wir mit Steal Time Überverkauf (Oversubscription) aufgespürt, aber manche älteren Rechenzentren glätten die CPU-Scheduling-Werte, sodass die Steal-Daten gar nicht mal so schlecht aussehen. Ziehen Sie jetzt keine voreiligen Schlüsse – konzentrieren Sie sich stattdessen auf den Disk-Cache, eine der Hardware-Komponenten, die am wenigsten lügt.

In der Praxis lasse ich fio üblicherweise zwei Runden laufen: zuerst einen Buffered-Write mit Page Cache testen, dann einen Direct-Write unter Umgehung des Cache. Die Befehle sehen ungefähr so aus:

# 第一轮：缓冲写（吃内存Cache）
fio --name=cache-test --rw=write --bs=1M --size=2G --direct=0 --ioengine=libaio --runtime=30 --time_based

# 第二轮：直写（绕Cache，直接落盘）
fio --name=direct-test --rw=write --bs=1M --size=2G --direct=1 --ioengine=libaio --runtime=30 --time_based

Achten Sie besonders auf das „Klippenverhältnis“ der beiden Messwerte. Bei neu ausgestatteten NVMe-Cloud-Disks erreicht der Direct-Write etwa 60–80 % des Buffered-Writes; bei alten Festplatten oder gemeinsam genutztem Storage kann der Direct-Write auf unter 10 % fallen. Wenn die Nennleistung 2000 MB/s beträgt, der Direct-Write jedoch nur 150 MB/s erreicht, ist das ein typischer Cache-Abbruch – die Daten täuschen Sie zuerst, und erst beim Schreiben auf die Platte zeigt sich die Wahrheit.

Diese Beweissicherung muss zusammen mit Steal Time betrachtet werden. Hohe Steal-Werte bedeuten, dass Nachbarn die CPU beanspruchen; der Disk-Cache-Einbruch zeigt, dass auch der Speicherkanal überlastet ist. Wenn beide Beweise zusammenkommen, kann man ziemlich sicher auf Überverkauf schließen – und zwar nicht nur auf einen einfachen Überverkauf, sondern auf eine Infrastruktur, deren zugrunde liegende Hardware schon ziemlich betagt ist.

Aus FinOps-Sicht sollte eine solche Maschine nur noch zum „Restwert“ abgerechnet werden. Wenn die Prämie für die angegebene Konfiguration mehr als 30 % über einer neuen Maschine liegt, sollten Sie direkt nachverhandeln oder den Preis senken; wenn das nicht klappt, wechseln Sie. Schließlich zahlen Sie für die Specs, nicht für eine Luftspiegelung auf dem Cache. Die vollständige Checkliste zur Vermeidung von Fallstricken finden Sie im Leitfaden zur Selbstprüfung bei übertriebenen Cloud-Server-Spezifikationen.

Aufschlagrate und Entscheidungsbaum zur Vermeidung von Fallstricken

Wenn Sie einen Cloud-Server mit „hohem Takt und alter CPU“ erhalten, zahlen Sie nicht sofort. Berechnen Sie zuerst die Aufschlagrate: (tatsächliche monatliche Zahlung – Marktpreis einer neuen CPU mit gleicher Konfiguration) / Marktpreis einer neuen CPU mit gleicher Konfiguration. Wenn der Aufschlag 30 % übersteigt, können Sie im Grunde davon ausgehen, dass Sie für ausgemusterte Hardware eine „Dummheitssteuer“ zahlen. Eine noch aggressivere Methode besteht darin, es direkt aus FinOps-Perspektive zu quantifizieren: Kann man mit demselben Geld eine AMD-EPYC-CPU mit doppelter Kernzahl oder eine neue Intel-CPU der letzten 3 Jahre bekommen? Wenn ja, dann sollte diese Anschaffung nicht genehmigt werden.

Dann folgen Sie meinem dreistufigen Entscheidungsbaum zur Beweissicherung:

1. Steal Time – den bösen Nachbarn fangen

   vmstat 1 10 | awk '{print $17}'  # 看 st 列

Wenn bei kontinuierlicher Abtastung der st-Mittelwert > 5 % beträgt oder Spitzen über 20 % auftreten, ist der Host stark überbucht und die CPU-Zeit wird vom Nachbarn gestohlen. Eine Downgrade-Konfiguration ist die einzige Möglichkeit, den Verlust zu begrenzen.

1. Disk-Cache-Klippentest

   dd if=/dev/zero of=/tmp/test bs=1M count=1024 conv=fdatasync

Beim ersten Schreiben in den Cache werden 1,5 GB/s erreicht, beim zweiten Mal fällt er auf 150 MB/s ab – der Cache ist nur Fassade. Das ist typisch für überbuchten Shared Storage. Alte Konfiguration + Disk-Klippe = doppelt übertriebene Spezifikationen.

1. Vergleich mit echten Benchmark-Ergebnissen

   curl -sL yabs.sh | bash

Einzelkern-Geekbench-5-Score unter 700, aber angegebener Takt 3,5 GHz? Gehen Sie direkt mit diesem Bericht zum Kundendienst und fordern Sie eine Rückerstattung der Preisdifferenz zu einer neuen 4-Kern-CPU oder eine Migration.

Zum Schluss eine harte Regel: Jede Werbeseite, die „hohe Leistung“ behauptet, aber vor dem Kauf keine Links zu echten Benchmark-Ergebnissen bereitstellt, wird als übertriebene Spezifikation behandelt. Vertrauen Sie nur eigenen Benchmarks und zahlen Sie Aufschläge nur für neue CPUs.