CPU IPC und Taktfrequenz: Hosting-Prozessoren richtig vergleichen

CPU IPC: Instruktionen pro Takt

CPU IPC steht für Instructions per Cycle, also Instruktionen pro Taktzyklus. Für einen abgegrenzten Messbereich wird üblicherweise die Zahl der abgeschlossenen Maschineninstruktionen durch die Zahl der im selben Bereich gezählten CPU-Zyklen geteilt. Ein IPC von 2 bedeutet in diesem Zusammenhang durchschnittlich zwei abgeschlossene Instruktionen pro gezähltem Zyklus.

Der Wert ist eine Eigenschaft der Ausführung, nicht eine feste Kennzahl für alle Aufgaben eines Prozessors. Dasselbe System kann bei einer Berechnung mit gut verfügbaren Daten einen anderen IPC erreichen als bei einer Datenbankabfrage, die häufig auf Daten aus dem Hauptspeicher warten muss. Auch der jeweilige Datensatz und der betrachtete Programmabschnitt verändern das Ergebnis.

Ein Cache hält häufig benötigte Daten nahe an der CPU. Muss ein Kern stattdessen auf langsamere Speicherzugriffe warten, können Ausführungseinheiten zeitweise ungenutzt bleiben. Ebenso beeinflussen Abhängigkeiten zwischen Instruktionen und Verzweigungen im Programmablauf, wie viel Arbeit sich gleichzeitig ausführen lässt. Ein niedriger IPC ist deshalb ein Anlass zur weiteren Untersuchung, aber noch keine eindeutige Diagnose.

Eine Maschineninstruktion ist außerdem keine genormte Einheit für eine abgeschlossene Webanfrage. Compiler, Befehlssatz und Vektorisierung können dazu führen, dass unterschiedliche Programme für dieselbe Aufgabe verschieden viele Instruktionen benötigen. Ein höherer IPC allein beweist daher weder eine kürzere Antwortzeit noch mehr Anfragen pro Sekunde.

Für einen Vergleich ist entscheidend, welche Anwendung und welcher Messbereich hinter dem Wert stehen. Eine IPC-Zahl ohne diese Angaben lässt offen, ob die Systeme überhaupt dieselbe Arbeit verrichten. Weitere Grundlagen zum Zusammenspiel von Takt, Kernen und Speicherhierarchie findest du im Beitrag zur CPU-Architektur im Hosting.

Server-Taktfrequenz und Boost verstehen

Die Taktfrequenz beschreibt, wie viele Zyklen eine CPU pro Sekunde durchläuft. Ein Gigahertz, kurz GHz, entspricht einer Milliarde Zyklen pro Sekunde. Der Wert sagt für sich genommen nicht, wie viele Instruktionen ein Programm in diesen Zyklen abschließt oder wie viel nutzbare Arbeit es damit erledigt.

In Datenblättern stehen häufig eine Basisfrequenz und ein maximaler Boost. Die Basisfrequenz dient als Spezifikationswert; der Boost bezeichnet eine höhere mögliche Frequenz unter passenden Bedingungen. Beide Angaben ersetzen keine Beobachtung des tatsächlich erreichten Takts während der konkreten Anwendung und ihrer jeweiligen Last.

Ein Beispiel ist der AMD EPYC 9655: Für dieses Modell nennt AMD 96 Kerne, 192 Threads, 2,6 GHz Basistakt und bis zu 4,5 GHz maximalen Boost. Diese Werte beschreiben die Ausstattung und Frequenzspezifikation des Prozessors. Sie sind weder ein gemessener IPC noch ein Nachweis für einen bestimmten Hosting-Durchsatz.

Für die EPYC-9005-Serie definiert AMD den maximalen Boost als höchste Frequenz, die ein einzelner Kern unter normalen Serverbetriebsbedingungen erreichen kann. Die bis zu 4,5 GHz des 9655 sind somit keine Zusage, dass alle 96 Kerne diesen Takt dauerhaft halten. Leistungs- und Temperaturgrenzen beeinflussen das Verhalten unter Last.

Für eine kurze Einzelaufgabe kann ein zeitweise höherer Takt relevant sein; bei lang anhaltender paralleler Last ist dagegen interessant, welche Leistung das System über die gesamte Laufzeit bereitstellt. Andere Modelle der Serie besitzen andere Frequenzen und Kernzahlen. Ein Vergleich allein anhand des größten GHz-Werts würde diese Unterschiede und die konkrete Anwendung ausblenden.

Kerne, Threads und virtuelle CPUs

Ein Prozess ist vereinfacht eine laufende Programminstanz. Darin führen ein oder mehrere Threads Anweisungen aus. Ein physischer CPU-Kern besitzt die Hardware zur Ausführung solcher Arbeit; Betriebssysteme sehen je nach Prozessor einen oder mehrere logische CPU-Threads pro Kern. Logische Threads desselben Kerns teilen sich dabei Teile seiner Hardware.

Eine Aufgabe mit einem stark seriellen Abschnitt kann diesen Teil nicht beliebig auf viele Kerne verteilen. Dort ist wichtig, wie schnell der ausführende Thread die konkrete Arbeit erledigt. Unabhängige Webanfragen lassen sich dagegen häufig parallel bearbeiten: Dann können zusätzliche verfügbare Kerne den Gesamtdurchsatz unterstützen, sofern andere Ressourcen nicht begrenzen.

Die Zahl logischer Threads ist nicht mit der Zahl unabhängiger physischer Kerne gleichzusetzen. Der EPYC 9655 hat beispielsweise 96 physische Kerne und 192 Threads laut Hersteller. Aus den 192 Threads folgt weder eine Verdopplung der Leistung gegenüber 96 Threads noch ein bestimmter Durchsatz für einen Webserver.

Bei einem virtuellen Server stellt der Anbieter dem Gastbetriebssystem vCPUs bereit. Eine vCPU ist nicht automatisch ein exklusiv nutzbarer physischer Kern: Ihre Zuordnung zur Host-Hardware kann je nach Angebot unterschiedlich ausfallen, und Rechenzeit kann mit anderen Gästen geteilt oder durch Limits begrenzt sein.

Frage vor der Auswahl nach der konkreten Ressourcenzusage: Ist CPU-Zeit garantiert oder wird sie geteilt? Gibt es dauerhafte Leistungsgrenzen und wie werden vCPUs zugeordnet? Eine hohe vCPU-Zahl hilft einer parallelen Anwendung nur insoweit, wie tatsächlich genügend Rechenzeit verfügbar ist; für einen seriellen Abschnitt ersetzt sie keine schnelle Ausführung auf einem Thread.

IPC und Takt gemeinsam rechnen

IPC und Taktfrequenz beschreiben unterschiedliche Seiten der CPU-Ausführung. Für einen passend abgegrenzten Messbereich lässt sich ihre Wirkung näherungsweise verbinden: Instruktionen pro Sekunde entsprechen dem IPC multipliziert mit den effektiven CPU-Zyklen pro Sekunde. Der IPC bezieht sich dabei auf die abgeschlossenen Instruktionen und die gezählten Zyklen im selben Bereich.

Illustratives Rechenbeispiel, keine Messung: Bei konstant angenommenen 2,0 Instruktionen pro Zyklus und 3,0 GHz ergeben sich rechnerisch 6,0 Milliarden Instruktionen pro Sekunde. Auch 1,5 IPC bei 4,0 GHz ergeben 6,0 Milliarden. In diesem Beispiel gleicht der höhere Takt also den niedrigeren IPC in der Rechnung aus.

Die gleichen Instruktionsraten bedeuten jedoch nicht, dass beide Systeme gleich viele Webanfragen bearbeiten. Für dieselbe Aufgabe können Programme je nach Compiler, Befehlssatz und verwendeten Befehlen unterschiedlich viele Instruktionen benötigen. Eine Instruktion ist deshalb keine einheitliche Menge erledigter Anwendungsarbeit.

Auch die Antwortzeit einer Website lässt sich aus dem Produkt nicht direkt ablesen. Ein Thread kann auf Daten vom Datenträger oder auf eine Netzwerkantwort warten; währenddessen erklärt seine Instruktionsrate nicht die gesamte verstrichene Zeit. Bei einer virtuellen Maschine kommt hinzu, dass sie nicht unbedingt jederzeit CPU-Zeit erhält.

Für einen Vergleich muss daher erkennbar sein, welcher Code und welcher Zeitraum erfasst wurden. Die Formel hilft, die aktive Ausführung einzuordnen; für die Hosting-Entscheidung sind zusätzlich abgeschlossene Aufgaben und ihre Antwortzeiten unter einem vergleichbaren Anfrageprofil nötig.

Datenblatt und Kennzahlen einordnen

Ein Datenblatt liefert nützliche Anhaltspunkte für die Auswahl einer Hosting-CPU. Die Angaben beantworten aber unterschiedliche Fragen: IPC beschreibt ein Verhalten im jeweiligen Messbereich, Frequenzangaben und Kernzahlen dagegen spezifizieren Eigenschaften eines Prozessormodells. Erst zusammen mit der Anwendung werden daraus brauchbare Vergleichskriterien.

Der EPYC 9655 zeigt, wie solche Angaben zusammengehören: Das Modell besitzt laut AMD 96 Kerne und 192 Threads, einen Basistakt von 2,6 GHz und bis zu 4,5 GHz maximalen Boost. Die 4,5 GHz sind kein zugesicherter Takt für alle Kerne unter Dauerlast und kein gemessener Hosting-Durchsatz.

Eine Rangliste nach maximalen GHz würde ausblenden, wie viel Arbeit verschiedene Prozessoren je Zyklus und je Aufgabe erledigen. Eine Rangliste nach Kernzahl übersieht dagegen, dass nicht jede Anwendung ihre Arbeit gleich gut parallel verteilen kann. Beide Angaben sind Ausgangspunkte, keine fertigen Leistungsurteile.

Achte bei Angeboten deshalb auf die Modellvariante und darauf, welche Ressourcen tatsächlich nutzbar sind. Für einen belastbaren Vergleich brauchst du außerdem ein passendes Lastprofil und Ergebnisse bei vergleichbarer Software und Konfiguration. Spezifikationen unterschiedlicher Modelle sollten nicht mit einem für die ganze Produktfamilie angenommenen Maximum vermischt werden.

Hosting-CPU nach Lastprofil auswählen

Welche CPU für Hosting geeignet ist, hängt davon ab, was der Server erledigen soll. Eine lange Einzelaufgabe stellt andere Anforderungen als viele unabhängige Webanfragen. Die Tabelle übersetzt typische Lastprofile in eine vorrangige Messgröße und eine Frage, die vor der Auswahl geklärt werden sollte.

Bei einer Einzelaufgabe ist die Leistung des ausführenden Threads besonders wichtig, wenn ein größerer Teil der Arbeit seriell abläuft. Mehr Kerne verkürzen diesen Teil nicht automatisch. Ein kurzer maximaler Boost reicht als Beleg für eine lang laufende Aufgabe ebenfalls nicht: Entscheidend ist ihre gemessene Laufzeit unter den vorgesehenen Bedingungen.

Viele unabhängige Anfragen können dagegen parallel bearbeitet werden. Hier zählt neben der Leistung pro Thread, wie viele Ressourcen gleichzeitig verfügbar sind und wie sich die Antwortzeiten bei steigender Last entwickeln. Die Summe nomineller GHz-Zahlen ersetzt keinen Vergleich des Gesamtdurchsatzes bei gleicher Parallelität.

Bei einer Datenbank mit großem Arbeitsdatensatz können Speicherzugriffe die Ausführung bremsen, wenn benötigte Daten nicht effektiv aus den Caches bedient werden. Ein niedriger IPC kann Anlass für weitere Untersuchungen sein, beweist aber nicht allein einen Speicherengpass. Prüfe daher auch Abfragen, Datenbestand und Speicherbestückung, bevor du die CPU austauschst.

Beim VPS ist zusätzlich die Ressourcenzusage entscheidend: Eine vCPU ist nicht automatisch ein exklusiver physischer Kern. Frage nach Zuordnung, möglichen CPU-Limits und der Teilung mit anderen Gästen. Erst mit diesen Angaben lässt sich ein Anwendungstest sinnvoll mit einem Angebot auf einem dedizierten Server vergleichen.

Vergleichbare Anwendungstests planen

Ein aussagekräftiger Vergleich beginnt bei deiner Anwendung, nicht bei einer isolierten CPU-Zahl. Lege für beide Hosting-Angebote dieselbe Softwareversion, denselben Datensatz und dieselbe Konfiguration fest. SPEC bezeichnet die eigene Anwendung auf der eigenen Infrastruktur als idealen Maßstab für die Produktauswahl.

Definiere anschließend ein Anfrageprofil, das die spätere Nutzung möglichst gut abbildet: etwa welche Seiten oder API-Endpunkte aufgerufen werden und wie viele Anfragen gleichzeitig eintreffen. Halte Parallelität und Ressourcenlimits zwischen den Durchläufen vergleichbar. Falls ein Angebot andere Limits vorgibt, dokumentiere sie ausdrücklich, statt den Unterschied allein der CPU zuzuschreiben.

Plane eine Aufwärmphase ein, damit beispielsweise die Anwendung gestartet ist und sich Caches füllen können. Danach helfen mehrere ausreichend lange Durchläufe, kurzfristige Schwankungen von einem wiederkehrenden Unterschied zu trennen. Dokumentiere auch, ob während der Messung weitere Aufgaben auf den Systemen liefen.

Erfasse neben dem Durchsatz die Antwortzeitverteilung und die Fehler. Ein höherer Durchschnitt an abgeschlossenen Anfragen pro Sekunde ist für sich wenig hilfreich, wenn einzelne Anfragen sehr lange warten oder häufiger scheitern. Vergleiche deshalb auch hohe Perzentile der Antwortzeit bei gleicher Parallelität.

Veröffentlichte SPEC-CPU2017-Ergebnisse können ergänzend Orientierung geben. SPECspeed misst die für Aufgaben benötigte Zeit, SPECrate den Durchsatz; die beiden Metriken sind nicht unmittelbar miteinander austauschbar. Vergleiche Ergebnisse derselben Metrik und beachte Systemkonfiguration und Software. Die CPU-Suite bildet Netzwerk und I/O eines vollständigen Hosting-Dienstes nicht ab.

IPC und Frequenz im Betrieb prüfen

Für eine eigene Linux-Testumgebung kannst du die abgeschlossenen Instruktionen und Zyklen eines vorhandenen, geprüften Programms mit perf erfassen. Im folgenden Beispiel ist testprogramm ein Platzhalter: Ersetze ihn durch dein Testprogramm und gegebenenfalls dessen Argumente. Der Befehl ist ein Messvorschlag, kein bereits ausgeführter Test.

perf stat -e '{instructions,cycles}' -- testprogramm

Die geschweiften Klammern fassen die Ereignisse zu einer Zählergruppe zusammen. Sie sollen gleichzeitig erfasst werden, was Fehler durch zeitversetztes Multiplexing verringern kann. Teile die gezählten Instruktionen durch die gezählten Zyklen, um den IPC für diesen Messbereich zu erhalten; perf kann diesen Wert auch direkt ausgeben.

Ob die Ereignisse verfügbar sind und gelesen werden dürfen, hängt von Hardware, Kernel, Berechtigungen und gegebenenfalls der Virtualisierungsumgebung ab. Eine nicht verfügbare oder nicht gemeinsam zählbare Ereignisgruppe liefert keinen belastbaren Vergleich. Ändere Sicherheitseinstellungen nicht allein für dieses Beispiel.

Auch eine Frequenzanzeige benötigt Kontext: scaling_cur_freq entspricht laut Kernel-Dokumentation in vielen Fällen dem zuletzt vom Treiber angeforderten Zustand und nicht zwingend dem tatsächlich erreichten Hardwaretakt. Der nicht überall verfügbare Wert cpuinfo_cur_freq soll dagegen die hardwareseitig ermittelte aktuelle Frequenz wiedergeben. Mehr zum CPU Governor auf Hosting-Servern erläutert die Steuerung der Frequenzskalierung.

Ein niedriger IPC ist ein Anhaltspunkt für weitere Untersuchungen, aber keine fertige Diagnose. Speicherzugriffe können die Ausführung ausbremsen; ebenso muss geprüft werden, welcher Programmteil gemessen wurde und ob andere Einflüsse vorliegen. Vergleiche den Zählerwert daher mit dem Verhalten der Anwendung und ihrem Datenzugriff.

Engpass erkennen und Upgrade entscheiden

Beginne bei einem konkreten Symptom: Werden Anfragen unter Last langsam, steigt die Fehlerrate oder dauert eine einzelne Aufgabe zu lange? Notiere, wann das Problem auftritt und welche Arbeit gleichzeitig läuft. Erst dann lässt sich prüfen, ob mehr CPU-Leistung die relevante Verzögerung überhaupt verkürzen kann.

Prüfe zunächst die verfügbare und genutzte CPU-Zeit. Eine dauerhaft rechenintensive Aufgabe kann von schnellerer Ausführung oder mehr nutzbarer Parallelität profitieren. Hohe Auslastung allein erklärt jedoch weder, welcher Code sie verursacht, noch ob die Antwortzeit vor allem dort entsteht. Stelle den Befund deshalb neben Durchsatz und Antwortzeiten derselben Lastphase.

Untersuche anschließend Speicherbedarf und Datenzugriffe. Muss eine Datenbank häufig auf Daten außerhalb des CPU-Caches zugreifen, kann sie auf Speicher warten; ein niedriger IPC kann darauf hinweisen, beweist den Grund aber nicht. Auch knapper Arbeitsspeicher, Datenträgerzugriffe oder langsame externe Dienste können die beobachtete Verzögerung prägen.

Bei einem VPS gehört die Ressourcenzusage zur Diagnose: Frage nach der Zuordnung der vCPUs, möglichen CPU-Limits und der Teilung mit anderen Gästen. Ein dedizierter Server bietet eine andere Zuordnung physischer Ressourcen, doch auch dort entscheiden Anwendung, Konfiguration und Lastprofil über das Ergebnis. Vergleiche beide Angebote möglichst mit demselben Anwendungstest.

Erwäge ein CPU-Upgrade, wenn die Messungen einen passenden CPU-Engpass zeigen und der neue Tarif die benötigte Rechenzeit tatsächlich bereitstellt. Liegt die Verzögerung überwiegend bei Speicher, Datenträger oder einem externen Dienst, ist dort die weitere Untersuchung sinnvoller. Halte den Ausgangszustand fest, damit du eine Änderung anschließend vergleichbar bewerten kannst.

Lies maximale Boost-Angaben nicht als garantierten Dauertakt aller Kerne und einen IPC-Wert nicht als universelle Eigenschaft der CPU. Ebenso wenig genügt eine einzelne Auslastungszahl für eine vollständige Engpassdiagnose. Die Entscheidung fällt anhand der konkreten Aufgabe und der tatsächlich verfügbaren Ressourcen, nicht anhand einer einzelnen Spitzenkennzahl.