CPU IPC beschreibt abgeschlossene Instruktionen pro Taktzyklus, die Taktfrequenz die Zyklen pro Sekunde. Keine der beiden Kennzahlen allein zeigt, wie schnell ein Hosting-Angebot deine Anwendung ausführt: IPC hängt vom Programm und seinen Daten ab, während der tatsächliche Takt unter Last von der Spezifikation abweichen kann. Für die Auswahl sind auch Parallelität und verfügbare CPU-Zeit entscheidend. Ein vergleichbarer Anwendungstest mit Durchsatz und Antwortzeiten liefert eine belastbarere Grundlage als ein einzelner GHz-Wert.
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 vCPU 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.
| Chiffre clé | Signification | Avantages | Frontière la plus importante |
|---|---|---|---|
| IPC | Abgeschlossene Instruktionen je gezähltem Zyklus | Ordnet die Ausführung im gemessenen Programm ein | Hängt von Programm und Daten ab; Instruktionen sind keine normierte Arbeitseinheit |
| Basisfrequenz | Données du fabricant concernant la fréquence fondamentale du modèle | Facilite le classement de la mesure spécifiée | Il n'y a pas de preuve du rythme atteint pour chaque tâche |
| Boost maximal | Fréquence de suralimentation maximale spécifiée | Indique le potentiel de fréquence supérieur | Valeur définie pour un seul cœur de l'EPYC 9005 dans des conditions de fonctionnement normales, et non comme fréquence d'horloge continue sur tous les cœurs |
| chiffre clé | Nombre de cœurs de processeur physiques | Indication de la capacité d'exécution parallèle disponible | Ce n'est pas à lui seul un indicateur du débit de l'application |
| Fils de discussion | Nombre de threads logiques de CPU pris en charge simultanément | Permet de classer les différentes possibilités d'exécution logique | Un thread logique ne correspond pas à un cœur physique supplémentaire |
L'EPYC 9655 illustre bien comment ces informations s'articulent entre elles : selon AMD, ce modèle dispose de 96 cœurs et 192 threads, d'une fréquence de base de 2,6 GHz et d'une fréquence boost maximale pouvant atteindre 4,5 GHz. Ces 4,5 GHz ne correspondent ni à une fréquence garantie pour tous les cœurs en charge continue, ni à un débit d'hébergement mesuré.
Un classement basé sur la fréquence maximale en GHz ne tiendrait pas compte de la charge de travail traitée par les différents processeurs par cycle et par tâche. À l'inverse, un classement basé sur le nombre de cœurs ne tient pas compte du fait que toutes les applications ne sont pas capables de répartir leur charge de travail de manière aussi efficace en parallèle. Ces deux indicateurs constituent des points de départ, et non des évaluations définitives des performances.
Fais donc attention aux Variante de modèle et sur les ressources réellement exploitables. Pour obtenir une comparaison fiable, tu as également besoin d'un profil de charge adapté et de résultats obtenus avec un logiciel et une configuration comparables. Il ne faut pas confondre les spécifications des différents modèles avec une valeur maximale supposée pour l'ensemble de la gamme de produits.
Hosting-CPU nach Lastprofil auswählen
Le choix d'un processeur adapté à l'hébergement dépend des tâches que le serveur doit effectuer. Une tâche unique de longue durée impose des exigences différentes de celles liées à de nombreuses requêtes Web indépendantes. Le tableau ci-dessous traduit les profils de charge typiques en un indicateur clé et en une question à clarifier avant de faire son choix.
| profil de charge | Paramètre prioritaire | Question avant l'achat |
|---|---|---|
| Tâche unique gourmande en ressources CPU | Durée de la tâche en question | À quelle vitesse le segment série concerné fonctionne-t-il sous une charge continue ? |
| Requêtes Web parallèles | Nombre de requêtes par seconde et répartition des temps de réponse pour un niveau de parallélisme défini | Quel débit les ressources exploitables permettent-elles d'atteindre avec un temps de réponse acceptable ? |
| Base de données gourmande en mémoire | Durée d'exécution et temps de réponse des requêtes représentatives | La capacité de mémoire et la configuration correspondent-elles à l'ensemble de données de travail ? |
| VPS | Débit des applications et temps de réponse dans le cadre des ressources garanties | Comment les vCPU sont-ils attribués et quelles sont les limites ou les divisions applicables au niveau du processeur ? |
Dans le cas d'une tâche unique, les performances du thread qui l'exécute sont particulièrement importantes lorsqu'une grande partie du travail s'effectue en série. Un nombre plus élevé de cœurs ne réduit pas automatiquement la durée de cette partie. De même, un bref pic de performance ne suffit pas à prouver l'efficacité d'une tâche de longue durée : ce qui est déterminant, c'est sa durée d'exécution mesurée dans les conditions prévues.
En revanche, de nombreuses requêtes indépendantes peuvent être traitées en parallèle. Dans ce cas, outre les performances par thread, ce qui compte, c'est le nombre de ressources disponibles simultanément et l'évolution des temps de réponse lorsque la charge augmente. La somme des GHz nominaux ne remplace pas une comparaison des Débit total à parallélisme égal.
Dans le cas d'une base de données contenant un volume important de données de travail, les accès à la mémoire peuvent ralentir l'exécution si les données requises ne sont pas fournies efficacement à partir des caches. Un faible IPC peut justifier des analyses plus approfondies, mais ne prouve pas à lui seul l'existence d'un goulot d'étranglement au niveau de la mémoire. Vérifie donc également les requêtes, le volume de données et la configuration de la mémoire avant de remplacer le processeur.
Avec le VPS, il y a en plus la engagement de ressources Point essentiel : un vCPU n'est pas automatiquement un cœur physique exclusif. Il faut se renseigner sur l'affectation, les limites éventuelles du processeur et le partage avec d'autres invités. Ce n'est qu'avec ces informations qu'il est possible de comparer de manière pertinente les résultats d'un test d'application avec une offre sur un serveur dédié.
Vergleichbare Anwendungstests planen
Une comparaison pertinente commence par votre application, et non par une simple valeur de CPU prise isolément. Définissez la même version logicielle, le même ensemble de données et la même configuration pour les deux offres d'hébergement. SPEC considère que votre propre application, exécutée sur votre propre infrastructure, constitue la référence idéale pour le choix d'un produit.
Définis ensuite un Profil de la demande, qui reflète au mieux l'utilisation future : par exemple, quelles pages ou quels points de terminaison API sont appelés et combien de requêtes arrivent simultanément. Veille à ce que le parallélisme et les limites de ressources restent comparables d'un passage à l'autre. Si une offre impose d'autres limites, documente-les explicitement, au lieu d'attribuer la différence uniquement au processeur.
Prévoyez une phase de préchauffage afin, par exemple, que l'application soit lancée et que les caches puissent se remplir. Ensuite, plusieurs cycles suffisamment longs permettront de distinguer les fluctuations à court terme d'une différence récurrente. Notez également si d'autres tâches s'exécutaient sur les systèmes pendant la mesure.
En plus du débit, enregistrez la Répartition des temps de réponse et les erreurs. Une moyenne plus élevée de requêtes traitées par seconde n'est guère utile en soi si certaines requêtes restent en attente très longtemps ou échouent fréquemment. Comparez donc également les centiles élevés du temps de réponse à un niveau de parallélisme identique.
Les résultats SPEC-CPU2017 publiés peuvent également servir de référence. SPECspeed mesure le temps nécessaire à l'exécution des tâches, tandis que SPECrate mesure le débit ; ces deux indicateurs ne sont pas directement interchangeables. Comparez les résultats d'un même indicateur et tenez compte de la configuration du système et des logiciels. La suite CPU ne reflète pas le réseau et les E/S d'un service d'hébergement complet.
IPC und Frequenz im Betrieb prüfen
Pour créer ton propre environnement de test sous Linux, tu peux utiliser perf pour enregistrer les instructions et les cycles terminés d'un programme existant et testé. Dans l'exemple suivant, testprogramm Un espace réservé : remplace-le par ton programme de test et, le cas échéant, par ses arguments. Cette commande est une suggestion de mesure, et non un test déjà exécuté.
Les accolades regroupent les événements en une seule Groupe de compteurs ensemble. Elles doivent être comptabilisées simultanément, ce qui permet de réduire les erreurs liées au multiplexage différé. Divisez le nombre d'instructions comptées par le nombre de cycles comptés pour obtenir l'IPC pour cette plage de mesure ; perf peut également afficher directement cette valeur.
La disponibilité et l'accessibilité des événements dépendent du matériel, du noyau, des autorisations et, le cas échéant, de l'environnement de virtualisation. Un groupe d'événements indisponible ou ne pouvant pas être comptabilisé ne permet pas d'établir une comparaison fiable. Ne modifiez pas les paramètres de sécurité uniquement pour les besoins de cet exemple.
Même l'affichage d'une fréquence doit être replacé dans son contexte : scaling_cur_freq selon la documentation du noyau, correspond dans de nombreux cas à la dernière valeur demandée par le pilote et pas nécessairement à la fréquence matérielle effectivement atteinte. Cette valeur, qui n'est pas disponible partout, cpuinfo_cur_freq doit en revanche afficher la fréquence actuelle détectée par le matériel. Pour en savoir plus sur Régulateur de CPU sur les serveurs d'hébergement explique le fonctionnement du réglage de la fréquence.
Un IPC faible constitue un indice justifiant des analyses plus approfondies, mais ne constitue pas un diagnostic définitif. Les accès à la mémoire peuvent ralentir l'exécution ; il convient également de vérifier quelle partie du programme a été mesurée et s'il existe d'autres facteurs influents. Comparez donc la valeur du compteur avec le comportement de l'application et ses accès aux données.
Engpass erkennen und Upgrade entscheiden
Commencez par un symptôme concret : les requêtes deviennent-elles lentes en cas de charge élevée, le taux d'erreurs augmente-t-il ou une tâche spécifique prend-elle trop de temps ? Notez à quel moment le problème survient et quelles tâches sont en cours d'exécution au même moment. Ce n'est qu'alors qu'il sera possible de vérifier si une puissance de calcul plus importante peut réellement réduire ce temps de latence.
Vérifie d'abord l'espace disponible et utilisé temps CPU. Une tâche nécessitant en permanence une forte puissance de calcul peut bénéficier d'une exécution plus rapide ou d'un parallélisme plus exploitable. Cependant, une charge élevée ne suffit pas à elle seule à expliquer quel code est à l'origine de ce phénomène, ni si le temps de réponse provient principalement de là. Comparez donc ce constat avec le débit et les temps de réponse observés lors de la même phase de charge.
Examinez ensuite les besoins en mémoire et les accès aux données. Si une base de données doit fréquemment accéder à des données situées en dehors du cache du processeur, elle peut être en attente de mémoire ; un faible IPC peut être un indice, mais ne prouve pas la cause. Une mémoire vive insuffisante, des accès aux périphériques de stockage ou des services externes lents peuvent également contribuer au retard observé.
Avec un VPS, la engagement de ressources Concernant le diagnostic : renseignez-vous sur l'affectation des vCPU, les limites éventuelles du processeur et le partage avec d'autres machines virtuelles. Un serveur dédié offre une autre répartition des ressources physiques, mais là encore, ce sont l'application, la configuration et le profil de charge qui déterminent le résultat. Comparez si possible les deux offres à l'aide du même test d'application.
Envisagez une mise à niveau du processeur si les mesures indiquent un goulot d'étranglement au niveau du processeur et si le nouveau forfait offre effectivement le temps de calcul nécessaire. Si le retard provient principalement de la mémoire, du support de données ou d'un service externe, il est plus judicieux de concentrer l'analyse sur ces éléments. Consigne l'état initial afin de pouvoir évaluer ultérieurement les changements de manière comparable.
Ne considérez pas les valeurs maximales de boost comme une fréquence de fonctionnement continue garantie pour tous les cœurs, ni une valeur d'IPC comme une caractéristique universelle du processeur. De même, un seul chiffre de charge de travail ne suffit pas pour établir un diagnostic complet des goulots d'étranglement. La décision doit être prise en fonction de la tâche concrète et des ressources réellement disponibles, et non sur la base d’un seul indicateur de pointe.
Sources et état des connaissances
État de la recherche :
État des recherches au 4 novembre 2026 ; l'exemple de fiche technique concerne l'AMD EPYC 9655. Pas de graphique, car il n'existe pas de valeurs de mesure comparables.
https://www.intel.com/pressroom/kits/core2duo/pdf/ICM_whitepaper.pdf
https://www.amd.com/content/dam/amd/en/documents/epyc-business-docs/datasheets/amd-epyc-9005-series-processor-datasheet.pdf
https://www.spec.org/cpu2017/Docs/overview.html
https://www.man7.org/linux/man-pages/man2/perf_event_open.2.html
https://www.man7.org/linux/man-pages/man1/perf-report.1.html
https://www.amd.com/en/products/processors/server/epyc/9005-series/amd-epyc-9655.html
https://www.man7.org/linux/man-pages/man1/perf-stat.1.html
https://www.man7.org/linux/man-pages/man1/perf-list.1.html
https://docs.kernel.org/admin-guide/pm/cpufreq.html




