Single-Core-Performance in der Cloud?
Hallo zusammen.
Wir möchten aktuelle eine Anwendung in die Azure-Cloud verschieben.
Dabei handelt es sich um eine in die Jahre gekommene Nischensoftware, die nicht unbedingt "cloud-ready" oder gar "native-cloud" etc. ist.
Beispielsweise ist alles noch eine 32bit-Anwendung, 2-Tier-Architektur, und der Kern der Anwendung läuft nur auf einem CPU-Kern.
Entsprechend suchen wir uns immer CPUs mit möglichst hoher Single-Core-Performance, um möglichst viel Geschwindigkeit raus zu holen. Lokal hat das auch immer zufriedenstellend funktioniert.
Wir virtualisieren Terminalserver, um die Latenz zwischen Applikation und Datenbank zu minimieren.
Pro TS haben wir 8 Sessions. Dann läuft also bereit 8x unsere Software auf der CPU.
Parallel dazu kommen die anderen VMs, und wir balancieren lokal den Load in dem Citrix-Cluster auch regelmäßig aus.
In der Cloud schaut das nun anders aus:
Die nahezu identische CPU bringt in Stress-Tests bei weitem nicht die gleichen Ergebnisse.
Und die Ergebnisse schwanken auch bisweilen deutlich in unseren Tests, es scheint "gute" und "schlechte" Tage zu geben, während wir on-premise sehr reproduzierbar sind.
Meine Gedanken dazu:
Azure gibt uns natürlich absolut keinen Einblick, wie viele weitere Subscriptions parallel auf der gleichen physikalischen Hardware gerade laufen. Da deren Geschäftsmodell wohl auf der maximalen Auslastung der HW beruhen wird, würde ich tendenziell mehr Load erwarten als bei uns lokal.
Ich frage mich nun gerade, ob wir die Cloud-CPUs nicht nach anderen Kritierien auswählen sollten.
Der maximale Takt auf einem Kern ist ja meines Verständnisses nach dann sehr hoch, wenn die CPU den Takt auf anderen Kernen reduzieren kann. Die thermische Last wird hin und her verschoben.
Wie hoch aber wäre denn die Wahrscheinlichkeit, dass ich die theoretisch mögliche Performance überhaupt mal zu Gesicht bekomme?
Würde ich mit der Auswahl einer CPU mit möglichst hoher Multi-Core-Performance nicht eine verlässlichere Größe bekommen, die dann auch nicht mehr unterschritten würde?
Was meint ihr?
Danke & Grüße,
Marcus
Wir möchten aktuelle eine Anwendung in die Azure-Cloud verschieben.
Dabei handelt es sich um eine in die Jahre gekommene Nischensoftware, die nicht unbedingt "cloud-ready" oder gar "native-cloud" etc. ist.
Beispielsweise ist alles noch eine 32bit-Anwendung, 2-Tier-Architektur, und der Kern der Anwendung läuft nur auf einem CPU-Kern.
Entsprechend suchen wir uns immer CPUs mit möglichst hoher Single-Core-Performance, um möglichst viel Geschwindigkeit raus zu holen. Lokal hat das auch immer zufriedenstellend funktioniert.
Wir virtualisieren Terminalserver, um die Latenz zwischen Applikation und Datenbank zu minimieren.
Pro TS haben wir 8 Sessions. Dann läuft also bereit 8x unsere Software auf der CPU.
Parallel dazu kommen die anderen VMs, und wir balancieren lokal den Load in dem Citrix-Cluster auch regelmäßig aus.
In der Cloud schaut das nun anders aus:
Die nahezu identische CPU bringt in Stress-Tests bei weitem nicht die gleichen Ergebnisse.
Und die Ergebnisse schwanken auch bisweilen deutlich in unseren Tests, es scheint "gute" und "schlechte" Tage zu geben, während wir on-premise sehr reproduzierbar sind.
Meine Gedanken dazu:
Azure gibt uns natürlich absolut keinen Einblick, wie viele weitere Subscriptions parallel auf der gleichen physikalischen Hardware gerade laufen. Da deren Geschäftsmodell wohl auf der maximalen Auslastung der HW beruhen wird, würde ich tendenziell mehr Load erwarten als bei uns lokal.
Ich frage mich nun gerade, ob wir die Cloud-CPUs nicht nach anderen Kritierien auswählen sollten.
Der maximale Takt auf einem Kern ist ja meines Verständnisses nach dann sehr hoch, wenn die CPU den Takt auf anderen Kernen reduzieren kann. Die thermische Last wird hin und her verschoben.
Wie hoch aber wäre denn die Wahrscheinlichkeit, dass ich die theoretisch mögliche Performance überhaupt mal zu Gesicht bekomme?
Würde ich mit der Auswahl einer CPU mit möglichst hoher Multi-Core-Performance nicht eine verlässlichere Größe bekommen, die dann auch nicht mehr unterschritten würde?
Was meint ihr?
Danke & Grüße,
Marcus
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 93714879627
Url: https://administrator.de/forum/single-core-performance-in-der-cloud-93714879627.html
Ausgedruckt am: 23.12.2024 um 00:12 Uhr
28 Kommentare
Neuester Kommentar
Moin,
in Azure bekommst du im Normalfall schlicht geshared Ressourcen und hast da auch keinen wirklichen Einfluss drauf.
Was du aber bedenken solltest ist eben welche CPU du auswählst. Für deinen Anwendungsfall gibt es entsprechende high performance CPUs. Wie die genau heißen muss ich selbst raus suchen. Die sind aber auch entsprechend teuer.
Gruß
Spirit.
in Azure bekommst du im Normalfall schlicht geshared Ressourcen und hast da auch keinen wirklichen Einfluss drauf.
Was du aber bedenken solltest ist eben welche CPU du auswählst. Für deinen Anwendungsfall gibt es entsprechende high performance CPUs. Wie die genau heißen muss ich selbst raus suchen. Die sind aber auch entsprechend teuer.
Gruß
Spirit.
Moin @mzurhorst,
ich würde es ja am liebsten schnell und schmerzlos machen, das letztere wird fürchte ich jedoch nicht funktionieren. 😬
Ähm, die Wahrscheinlichkeit liegt bei einer gesharten Instanz bei ~0, sorry. 😔
Meiner bisherigen Erfahrung nach, bekommst du ein solches Problem nur damit gelöst, in dem du nochmals eine ganze Menge mehr Geld in die Hand nimmst und dir bei MS exklusive Hardware für die eigene Instanz buchst. 😔
Gruss Alex
Wie hoch aber wäre denn die Wahrscheinlichkeit, dass ich die theoretisch mögliche Performance überhaupt mal zu Gesicht bekomme?
ich würde es ja am liebsten schnell und schmerzlos machen, das letztere wird fürchte ich jedoch nicht funktionieren. 😬
Ähm, die Wahrscheinlichkeit liegt bei einer gesharten Instanz bei ~0, sorry. 😔
Würde ich mit der Auswahl einer CPU mit möglichst hoher Multi-Core-Performance nicht eine verlässlichere Größe bekommen, die dann auch nicht mehr unterschritten würde?
Meiner bisherigen Erfahrung nach, bekommst du ein solches Problem nur damit gelöst, in dem du nochmals eine ganze Menge mehr Geld in die Hand nimmst und dir bei MS exklusive Hardware für die eigene Instanz buchst. 😔
Gruss Alex
You get what you pay for, wenn du vorhersagbare Compute-Power in Azure benötigst musst du das auch entsprechend bezahlen...
https://azure.microsoft.com/de-de/pricing/reserved-vm-instances
https://azure.microsoft.com/de-de/pricing/reserved-vm-instances
Moin @11078840001,
wenn der TO das entsprechende Angebot bekommt, dann merkt er aber auch ganz schnell, dass seine bisherige "On-Premise" Umgebung, dann doch nicht ganz so teuer gewesen ist. 🙃
Und selbst wenn er bei MS exklusive Hardware buchen würde, würde das, das Problem mit der generell höheren Latenz zwischen Wolke und LAN im Gegensatz zu der niedrigen bei LAN zu LAN, auch nicht lösen.
Das beste Beispiel ist z.B. Exchange Online. Bei einem grösseren Postfach kannst du das Arbeiten im Outlook ohne aktiviertes Caching fast knicken, bei einem On-Premise Exchange, klappt das meistens hingegen ohne grössere Probleme.
Gruss Alex
You get what you pay for, wenn du vorhersagbare Compute-Power in Azure benötigst musst du das auch entsprechend bezahlen...
https://azure.microsoft.com/de-de/pricing/reserved-vm-instances
https://azure.microsoft.com/de-de/pricing/reserved-vm-instances
wenn der TO das entsprechende Angebot bekommt, dann merkt er aber auch ganz schnell, dass seine bisherige "On-Premise" Umgebung, dann doch nicht ganz so teuer gewesen ist. 🙃
Und selbst wenn er bei MS exklusive Hardware buchen würde, würde das, das Problem mit der generell höheren Latenz zwischen Wolke und LAN im Gegensatz zu der niedrigen bei LAN zu LAN, auch nicht lösen.
Das beste Beispiel ist z.B. Exchange Online. Bei einem grösseren Postfach kannst du das Arbeiten im Outlook ohne aktiviertes Caching fast knicken, bei einem On-Premise Exchange, klappt das meistens hingegen ohne grössere Probleme.
Gruss Alex
Joa, die Cloud ist halt auch nur nen Computer unter fremder Hand in dessen Abhängigkeit man sich begibt und die auch nur so viel taugt, ob, wie, und wie gut sie erreichbar ist, von der Perf mal abgesehen.
Aber das sollte ja eigentlich jedem klar sein der fremde Clouds nutzt.
Aber das sollte ja eigentlich jedem klar sein der fremde Clouds nutzt.
Zitat von @mzurhorst:
Würde ich mit der Auswahl einer CPU mit möglichst hoher Multi-Core-Performance nicht eine verlässlichere Größe bekommen, die dann auch nicht mehr unterschritten würde?
Moin,Würde ich mit der Auswahl einer CPU mit möglichst hoher Multi-Core-Performance nicht eine verlässlichere Größe bekommen, die dann auch nicht mehr unterschritten würde?
aus meiner Sicht würde es in deinem Fall helfen eine Compute Optimzed SKU zu wählen, vielleicht ne Fsv2 (Turbo von 3.4 GHz auf allen Kernen) oder so.
/Thomas
Zitat von @Th0mKa:
aus meiner Sicht würde es in deinem Fall helfen eine Compute Optimzed SKU zu wählen, vielleicht ne Fsv2 (Turbo von 3.4 GHz auf allen Kernen) oder so.
/Thomas
Zitat von @mzurhorst:
Würde ich mit der Auswahl einer CPU mit möglichst hoher Multi-Core-Performance nicht eine verlässlichere Größe bekommen, die dann auch nicht mehr unterschritten würde?
Moin,Würde ich mit der Auswahl einer CPU mit möglichst hoher Multi-Core-Performance nicht eine verlässlichere Größe bekommen, die dann auch nicht mehr unterschritten würde?
aus meiner Sicht würde es in deinem Fall helfen eine Compute Optimzed SKU zu wählen, vielleicht ne Fsv2 (Turbo von 3.4 GHz auf allen Kernen) oder so.
/Thomas
Darauf wollte ich hinaus. Zu einem gewissen Maße sind die Ressourcen dann auch garantiert.
Moin,
wenn es um eine Sonderlösung geht, könnt Ihr auch prüfen ob ein Sonderweg funktioniert.
Bei Hetzner einen Ded. Server buchen mit schneller CPU mit Hyper-V und darauf die App-VM und eine RDS-VM.
Ja, das bringt viele neue Fragen und auch neue Probleme mit sich.
Löst aber das Performance-Problem.
i9-13900 https://www.intel.de/content/www/de/de/products/sku/230499/intel-core-i9 ...
Xeon Gold 5412u https://www.intel.de/content/www/de/de/products/sku/232374/intel-xeon-go ...
Ryzen 9 7950x3d https://www.amd.com/de/products/apu/amd-ryzen-9-7950x3d
wenn es um eine Sonderlösung geht, könnt Ihr auch prüfen ob ein Sonderweg funktioniert.
Bei Hetzner einen Ded. Server buchen mit schneller CPU mit Hyper-V und darauf die App-VM und eine RDS-VM.
Ja, das bringt viele neue Fragen und auch neue Probleme mit sich.
Löst aber das Performance-Problem.
i9-13900 https://www.intel.de/content/www/de/de/products/sku/230499/intel-core-i9 ...
Xeon Gold 5412u https://www.intel.de/content/www/de/de/products/sku/232374/intel-xeon-go ...
Ryzen 9 7950x3d https://www.amd.com/de/products/apu/amd-ryzen-9-7950x3d
Zitat von @11078840001:
You get what you pay for, wenn du vorhersagbare Compute-Power in Azure benötigst musst du das auch entsprechend bezahlen...
https://azure.microsoft.com/de-de/pricing/reserved-vm-instances
You get what you pay for, wenn du vorhersagbare Compute-Power in Azure benötigst musst du das auch entsprechend bezahlen...
https://azure.microsoft.com/de-de/pricing/reserved-vm-instances
RIs haben rein gar nichts mit "vorhersagbarer" Compute-Power zu tun. RIs sind am Ende nichts anderes, als vertraglich zugesicherte Ressourcen, über eine Laufzeit X.
Microsoft "belohnt" dieses Commitment mit einem Rabatt, gegenüber pay-as-you-go.
Das ist aber keine eigene Hardware, sondern nur die Garantie das deine reservierte VM-Größe dir immer zur Verfügung steht. Nicht reservierte Instanzen können z.B. aus einem "Stopped / Deallocated" Status nicht zurückgeholt werden, sollten in dem jeweiligen Moment / Geolokation nicht genügend Ressourcen zur Verfügung stehen.
"Dedicated Hosts" bei Azure bekommt man nur, wenn man das gleichnamige Produkt kauft / bucht. Siehe: https://azure.microsoft.com/de-de/products/virtual-machines/dedicated-ho ...
Mit Dedicated Hosts würde ich persönlich aber nicht starten, erst mal schauen ob die "klassischen" VMs auch herhalten, was sie tun sollten.
Das ist schon mal nicht verkehrt. Die FX-Serie wird mit einem Intel Xeon Gold 6246R betrieben, welcher immerhin schon mal bis 4.0ghz via Boost takten kann.
Zitat von @MysticFoxDE:
Und selbst wenn er bei MS exklusive Hardware buchen würde, würde das, das Problem mit der generell höheren Latenz zwischen Wolke und LAN im Gegensatz zu der niedrigen bei LAN zu LAN, auch nicht lösen.
Das beste Beispiel ist z.B. Exchange Online. Bei einem grösseren Postfach kannst du das Arbeiten im Outlook ohne aktiviertes Caching fast knicken, bei einem On-Premise Exchange, klappt das meistens hingegen ohne grössere Probleme.
Gruss Alex
Und selbst wenn er bei MS exklusive Hardware buchen würde, würde das, das Problem mit der generell höheren Latenz zwischen Wolke und LAN im Gegensatz zu der niedrigen bei LAN zu LAN, auch nicht lösen.
Das beste Beispiel ist z.B. Exchange Online. Bei einem grösseren Postfach kannst du das Arbeiten im Outlook ohne aktiviertes Caching fast knicken, bei einem On-Premise Exchange, klappt das meistens hingegen ohne grössere Probleme.
Gruss Alex
Azure mit M365 zu vergleichen ist Schwachsinnig. Wir reden hier von IaaS-Workloads, während M365 SaaS-Workloads sind. Anzunehmen, dass Latenz & co identisch sein, zeugt nicht von realer Praxiserfahrung in dem Bereich.
Mit einer Express Route zwischen einem lokalen Standort und der gewünschten Azure-Region, bekommt man identische Latenzen wie bei jedem anderen (lokalen) RZ-Anbieter, wo man 2-3 Racks stehen hat. Für 90% aller Workloads reichen diese Latenzen vollkommen aus. Bei externen RZs, welche ja am Ende auch nur eine "Cloud" sind schreit ja auch keiner bzgl. zu hoher Latenzen rum.
Moin @Cloudrakete,
Azure mit M365 zu vergleichen ist Schwachsinnig. Wir reden hier von IaaS-Workloads, während M365 SaaS-Workloads sind. Anzunehmen, dass Latenz & co identisch sein, zeugt nicht von realer Praxiserfahrung in dem Bereich.
was ich zu Exchange geschrieben habe, wird jeder bestätigen, der das schon hinter sich hat. 😉
Und was den Rest angeht, ähm, dir ist schon aufgefallen um was es hier bei diesem Post genau geht. 🤨
Ich bin bis zu einer gewissen Unetrnehmensgrösse/Struktur, auch bestimmt kein Freund von einem externen RZ.
Den Latenz hat in den meisten Fällen direkt etwas mit der Entfernung zu einem solchen zu tun und je näher die Daten bei den Usern liegen umso schneller können diese in Normalfall auch auf die zugreifen. 😁
Gruss Alex
Und selbst wenn er bei MS exklusive Hardware buchen würde, würde das, das Problem mit der generell höheren Latenz zwischen Wolke und LAN im Gegensatz zu der niedrigen bei LAN zu LAN, auch nicht lösen.
Das beste Beispiel ist z.B. Exchange Online. Bei einem grösseren Postfach kannst du das Arbeiten im Outlook ohne aktiviertes Caching fast knicken, bei einem On-Premise Exchange, klappt das meistens hingegen ohne grössere Probleme.
Gruss Alex
Das beste Beispiel ist z.B. Exchange Online. Bei einem grösseren Postfach kannst du das Arbeiten im Outlook ohne aktiviertes Caching fast knicken, bei einem On-Premise Exchange, klappt das meistens hingegen ohne grössere Probleme.
Gruss Alex
Azure mit M365 zu vergleichen ist Schwachsinnig. Wir reden hier von IaaS-Workloads, während M365 SaaS-Workloads sind. Anzunehmen, dass Latenz & co identisch sein, zeugt nicht von realer Praxiserfahrung in dem Bereich.
was ich zu Exchange geschrieben habe, wird jeder bestätigen, der das schon hinter sich hat. 😉
Und was den Rest angeht, ähm, dir ist schon aufgefallen um was es hier bei diesem Post genau geht. 🤨
Mit einer Express Route zwischen einem lokalen Standort und der gewünschten Azure-Region, bekommt man identische Latenzen wie bei jedem anderen (lokalen) RZ-Anbieter, wo man 2-3 Racks stehen hat. Für 90% aller Workloads reichen diese Latenzen vollkommen aus. Bei externen RZs, welche ja am Ende auch nur eine "Cloud" sind schreit ja auch keiner bzgl. zu hoher Latenzen rum.
Ich bin bis zu einer gewissen Unetrnehmensgrösse/Struktur, auch bestimmt kein Freund von einem externen RZ.
Den Latenz hat in den meisten Fällen direkt etwas mit der Entfernung zu einem solchen zu tun und je näher die Daten bei den Usern liegen umso schneller können diese in Normalfall auch auf die zugreifen. 😁
Gruss Alex
Zitat von @MysticFoxDE:
Den Latenz hat in den meisten Fällen direkt etwas mit der Entfernung zu einem solchen zu tun und je näher die Daten bei den Usern liegen umso schneller können diese in Normalfall auch auf die zugreifen. 😁
Den Latenz hat in den meisten Fällen direkt etwas mit der Entfernung zu einem solchen zu tun und je näher die Daten bei den Usern liegen umso schneller können diese in Normalfall auch auf die zugreifen. 😁
Es geht hier um eine Terminalserverlösung, Latenz zwischen Cloud und Nutzer ist da kein Thema.
Wir virtualisieren Terminalserver, um die Latenz zwischen Applikation und Datenbank zu minimieren.
/Thomas
Moin @Th0mKa,
Es geht hier um eine Terminalserverlösung, Latenz zwischen Cloud und Nutzer ist da kein Thema.
ja, zwischen dem User und der Terminalserver ist die Latenz nicht ganz so kritisch, bei manchen Fällen wie z.B. der CAD-Bearbeitung ist die aber auch bei RDS Umgebungen nicht unwichtig.
Ausserdem war die Aussage pauschal gemeint und nicht nur auf diesen Post bezogen.
Und spätestens zwischen Terminalserver und den DB's, ist das Thema mit der Latenz, auch bei diesem Post mehr als nur wichtig, den die Probleme des TO's können eventuell auch damit zusammenhängen.
Gruss Alex
Zitat von @MysticFoxDE:
Den Latenz hat in den meisten Fällen direkt etwas mit der Entfernung zu einem solchen zu tun und je näher die Daten bei den Usern liegen umso schneller können diese in Normalfall auch auf die zugreifen. 😁
Den Latenz hat in den meisten Fällen direkt etwas mit der Entfernung zu einem solchen zu tun und je näher die Daten bei den Usern liegen umso schneller können diese in Normalfall auch auf die zugreifen. 😁
Es geht hier um eine Terminalserverlösung, Latenz zwischen Cloud und Nutzer ist da kein Thema.
ja, zwischen dem User und der Terminalserver ist die Latenz nicht ganz so kritisch, bei manchen Fällen wie z.B. der CAD-Bearbeitung ist die aber auch bei RDS Umgebungen nicht unwichtig.
Ausserdem war die Aussage pauschal gemeint und nicht nur auf diesen Post bezogen.
Wir virtualisieren Terminalserver, um die Latenz zwischen Applikation und Datenbank zu minimieren.
Und spätestens zwischen Terminalserver und den DB's, ist das Thema mit der Latenz, auch bei diesem Post mehr als nur wichtig, den die Probleme des TO's können eventuell auch damit zusammenhängen.
Gruss Alex
Zitat von @mzurhorst:
Unsere Probleme begannen tatsächlich erst in dem Moment, wo die FX4 trotz genehmigtem Quota Request nicht mehr zur Verfügung stand, und unsere PYAG VMs "plötzlich und unerwartet" nach mehreren Monaten erstmals nicht mehr rebooten konnten.
Seitdem suchen wir neue Server, und diese Suche ist stark eingeschränkt durch den Fokus auf Single-Core-Performance.
Diesem Problem könnt ihr ja durch Reserved Instances begegnen und auch noch Geld sparen, wenn ich dich richtig verstanden habe ist euer Umfeld ja eher statisch.Unsere Probleme begannen tatsächlich erst in dem Moment, wo die FX4 trotz genehmigtem Quota Request nicht mehr zur Verfügung stand, und unsere PYAG VMs "plötzlich und unerwartet" nach mehreren Monaten erstmals nicht mehr rebooten konnten.
Seitdem suchen wir neue Server, und diese Suche ist stark eingeschränkt durch den Fokus auf Single-Core-Performance.
Bei Payg kommt es in der Praxis immer mal wieder vor das einzelne Standorte ausgelastet sind, es ist für MS halt schwierig die Auslastung vorherzusagen wenn die Last stark schwankt.
/Thomas
Hallo,
Euer primäres Problem ist doch diese Single-Core-Anwendung.
Die meisten Cloud-Anwendung sind Massiv-Multi-Core ausgelegt und dem folgen die Hardwarehersteller.
Das relativiert sich gerade ein bisschen, aber nur wenig.
AMD EPYC™ 9654, 96 Kerne, 2.4 - 3.7 GHz
Max Single-Core = 3.7 GHz
Max Multi-Core = 96 * 3,55 = 340,8 GHz (Milchmädchenrechnung)
vs
Intel i9-12900K, 8 Performance-Kerne, 3.2 - 6.0 GHz
Max Single-Core = 6.0 GHz
Max Multi-Core = 8 * 6 = 48 GHz (Milchmädchenrechnung)
Bis auf Hetzner bekommst Du einen i9 aber nicht im RZ.
Gibt es denn eine Option oder Planung die Anwendung zu erneuern?
Aus technischer Sicht schlägt man damit ganz viele Fliegen.
Stefan
Euer primäres Problem ist doch diese Single-Core-Anwendung.
Die meisten Cloud-Anwendung sind Massiv-Multi-Core ausgelegt und dem folgen die Hardwarehersteller.
Das relativiert sich gerade ein bisschen, aber nur wenig.
AMD EPYC™ 9654, 96 Kerne, 2.4 - 3.7 GHz
Max Single-Core = 3.7 GHz
Max Multi-Core = 96 * 3,55 = 340,8 GHz (Milchmädchenrechnung)
vs
Intel i9-12900K, 8 Performance-Kerne, 3.2 - 6.0 GHz
Max Single-Core = 6.0 GHz
Max Multi-Core = 8 * 6 = 48 GHz (Milchmädchenrechnung)
Bis auf Hetzner bekommst Du einen i9 aber nicht im RZ.
Gibt es denn eine Option oder Planung die Anwendung zu erneuern?
Aus technischer Sicht schlägt man damit ganz viele Fliegen.
Stefan
Moin @StefanKittel,
zum Einen passen hier ein paar Angaben nicht so wirklich zu der entsprechenden CPU und zum Anderen interpretierst du die Max Multi-Core Performance nicht ganz richtig.
Aber alles der Reihe nach.
Das sind die Hersteller Angaben von Intel zu einem i9-12900K.
Der Maximale Takt "Max Turbo Frequency" eines P-Cores, liegt bei diesem im Normallfall bei 5,2 GHz.
Diese Maximale Taktrate ist jedoch nur dann garantiert, wenn nur ein Kern belastet wird und die anderen nichts zu tun haben. Da es eine K CPU ist, ist hier zudem je nach Kühlung noch etwas Luft nach oben offen, aber auch nach unten, wenn die Kühlung nicht passt. 🙃
Die nächste relevante Angabe, die "Performance-core Max Turbo Frequency", die bei dieser CPU mit 5,1 GHz angegeben wird, gilt z.B. nur dann, wenn nicht mehr wie zwei der P-Cores belastet sind.
Und erst die "Performance-core Base Frequency" die beim i9-12900K bei 3,2 GHz liegt, gibt die garantierte Kernleistung aller Kerne bei Vollast an, aber, nur dann wenn die Kühlleistung des verwendeten CPU-Kühlers passt.
Sprich, die +- garantierte Gesamtleistung der P-Kerne einer i9-12900K CPU, liegt bei ~8x3,2 GHz= 25,6GHz und nicht 48 GHz.
Aber auch die 25,6GHz sind nicht in Stein gemeißelt, denn die liefert die CPU dauerhaft nur dann, wenn deren Kühlsystem dauerhaft auch die Abwärme von 125W abtransportieren kann. Wenn das entsprechende Kühlsystem schwächer ist, dann kannst du auch die 25,6GHz kicken, zumindest dauerhaft. Wenn dein Kühlsystem jedoch deutlich mehr Abwärme von der CPU abführen kann, dann kannst du auch mit deutlich mehr wie 25,6GHz rechnen.
Und dann kommen beim i9-12900K noch dessen E-Kerne hinzu, bei denen verhält es sich aber sehr ähnlich.
Ich habe in meiner Workstation z.B. einen i9-9820X verbaut, der von einer >250W WaKü gekühlt wird und daher können auch alle seine Kerne, selbst bei Vollast mit 4,4 GHz durchtuckern, ja OK, eher durchflitzen, obwohl Intel bei dieser CPU die "Max Turbo Frequency", also, die maximale Leistung bei Last über nur einen Kern, mit max. 4,1 GHz angibt. 🤪
Hier ist übrigens Intel ein kleiner Fehler passiert, bin mal gespannt ob er auch jemand anders auffällt. 🙃
Gruss Alex
Intel i9-12900K, 8 Performance-Kerne, 3.2 - 6.0 GHz
Max Single-Core = 6.0 GHz
Max Multi-Core = 8 * 6 = 48 GHz (Milchmädchenrechnung)
Max Single-Core = 6.0 GHz
Max Multi-Core = 8 * 6 = 48 GHz (Milchmädchenrechnung)
zum Einen passen hier ein paar Angaben nicht so wirklich zu der entsprechenden CPU und zum Anderen interpretierst du die Max Multi-Core Performance nicht ganz richtig.
Aber alles der Reihe nach.
Das sind die Hersteller Angaben von Intel zu einem i9-12900K.
Der Maximale Takt "Max Turbo Frequency" eines P-Cores, liegt bei diesem im Normallfall bei 5,2 GHz.
Diese Maximale Taktrate ist jedoch nur dann garantiert, wenn nur ein Kern belastet wird und die anderen nichts zu tun haben. Da es eine K CPU ist, ist hier zudem je nach Kühlung noch etwas Luft nach oben offen, aber auch nach unten, wenn die Kühlung nicht passt. 🙃
Die nächste relevante Angabe, die "Performance-core Max Turbo Frequency", die bei dieser CPU mit 5,1 GHz angegeben wird, gilt z.B. nur dann, wenn nicht mehr wie zwei der P-Cores belastet sind.
Und erst die "Performance-core Base Frequency" die beim i9-12900K bei 3,2 GHz liegt, gibt die garantierte Kernleistung aller Kerne bei Vollast an, aber, nur dann wenn die Kühlleistung des verwendeten CPU-Kühlers passt.
Sprich, die +- garantierte Gesamtleistung der P-Kerne einer i9-12900K CPU, liegt bei ~8x3,2 GHz= 25,6GHz und nicht 48 GHz.
Aber auch die 25,6GHz sind nicht in Stein gemeißelt, denn die liefert die CPU dauerhaft nur dann, wenn deren Kühlsystem dauerhaft auch die Abwärme von 125W abtransportieren kann. Wenn das entsprechende Kühlsystem schwächer ist, dann kannst du auch die 25,6GHz kicken, zumindest dauerhaft. Wenn dein Kühlsystem jedoch deutlich mehr Abwärme von der CPU abführen kann, dann kannst du auch mit deutlich mehr wie 25,6GHz rechnen.
Und dann kommen beim i9-12900K noch dessen E-Kerne hinzu, bei denen verhält es sich aber sehr ähnlich.
Ich habe in meiner Workstation z.B. einen i9-9820X verbaut, der von einer >250W WaKü gekühlt wird und daher können auch alle seine Kerne, selbst bei Vollast mit 4,4 GHz durchtuckern, ja OK, eher durchflitzen, obwohl Intel bei dieser CPU die "Max Turbo Frequency", also, die maximale Leistung bei Last über nur einen Kern, mit max. 4,1 GHz angibt. 🤪
Hier ist übrigens Intel ein kleiner Fehler passiert, bin mal gespannt ob er auch jemand anders auffällt. 🙃
Gruss Alex
Zitat von @MysticFoxDE:
Moin @StefanKittel,
zum Einen passen hier ein paar Angaben nicht so wirklich zu der entsprechenden CPU und zum Anderen interpretierst du die Max Multi-Core Performance nicht ganz richtig.
Gruss Alex
Moin @StefanKittel,
zum Einen passen hier ein paar Angaben nicht so wirklich zu der entsprechenden CPU und zum Anderen interpretierst du die Max Multi-Core Performance nicht ganz richtig.
Gruss Alex
Deshalb steht da "Milchmädchenrechnung" und die Gesamt-Performance vergleichbar zu machen. Da kommen ja auch die Eco-Kerne noch dazu. Für sein Problem sind ja nur 1 Kerne á 6.0 GHz relevant.
Zitat von @StefanKittel:
Hallo Alex,Zitat von @MysticFoxDE:
Moin @StefanKittel,
zum Einen passen hier ein paar Angaben nicht so wirklich zu der entsprechenden CPU und zum Anderen interpretierst du die Max Multi-Core Performance nicht ganz richtig.
Gruss Alex
Moin @StefanKittel,
zum Einen passen hier ein paar Angaben nicht so wirklich zu der entsprechenden CPU und zum Anderen interpretierst du die Max Multi-Core Performance nicht ganz richtig.
Gruss Alex
Deshalb steht da "Milchmädchenrechnung" um die Gesamt-Performance vergleichbar zu machen. Da kommen ja auch die Eco-Kerne noch dazu.
Für sein Problem sind ja nur 1 Kerne á 6.0 GHz relevant.
Stefan
Moin @StefanKittel,
auch abgesehen von den E-Kernen, lässt sich die Leistung moderner CPU's selbst beim selben Model leider nicht 1:1 untereinander vergleichen, weil diese extrem von der tatsächlich verwendeten Kühlung und auch der Geschwindigkeit der RAM's abhängig ist.
Nein, eben nicht, den der TO möchte nicht das nur ein Kern so schnell wie möglich läuft, sondern alle.
Ausserdem sehe ich nach der weiteren, etwas detaillierteren Beschreibung von TO, abgesehen von der CPU Leistung,
noch diverse weitere Gründe für die von ihm genannten Leistungsschwankungen. 😔
Gruss Alex
Deshalb steht da "Milchmädchenrechnung" um die Gesamt-Performance vergleichbar zu machen. Da kommen ja auch die Eco-Kerne noch dazu.
auch abgesehen von den E-Kernen, lässt sich die Leistung moderner CPU's selbst beim selben Model leider nicht 1:1 untereinander vergleichen, weil diese extrem von der tatsächlich verwendeten Kühlung und auch der Geschwindigkeit der RAM's abhängig ist.
Für sein Problem sind ja nur 1 Kerne á 6.0 GHz relevant.
Nein, eben nicht, den der TO möchte nicht das nur ein Kern so schnell wie möglich läuft, sondern alle.
Ausserdem sehe ich nach der weiteren, etwas detaillierteren Beschreibung von TO, abgesehen von der CPU Leistung,
noch diverse weitere Gründe für die von ihm genannten Leistungsschwankungen. 😔
Gruss Alex
Moin @mzurhorst,
wir meinen schon dasselbe, wir schauen nur von unterschiedlichen Seiten darauf. 😉
Na ja, die theoretisch möglich und die dauerhaft verfügbare Performance, ist in der Wolke eben nicht einfach zu kalkulieren, da auf den entsprechenden Nodes im Normallfall ja nicht nur euere VM's, sondern auch die von vielen anderen mitlaufen, daher kann man bei so einem Konstrukt eine hohe Singlethreadleistung meist auch eher knicken.
Zudem verwendet Microsoft in seinen Rechenzentren auch nicht gerade die CPU's, die einen ordentliche Singlethreadperformance liefern.
So wie ich sehe, verwenden die bei Dv5 oder Dsv5 entweder den 8370C oder 8473C Xeons.
Das sind jedoch beides CPU's die mit ihren =>52 Kernen eher dafür ausgelegt sind, parallel soviel Tasks wie möglich, aber nicht wirklich eine bestimmten Task so schnell wie möglich auszuführen. 😔
Da bei den meisten Anwendungen unserer Kunden die Singlethreadleistung auch sehr wichtig ist, verwenden wir bei neuen Systemen z.B. fast nur die folgenden CPU's ...
https://ark.intel.com/content/www/us/en/ark/products/237569/intel-xeon-g ...
... weil die selbst unter Last nicht unter 3,6 GHz einknicken. 😁
Die von MS verwendeten CPU's, können bei Last jedoch auf ~2GHz oder im schlimmsten Fall auch darunter einbrechen. 😔
Was heisst den "Es ist nichts abgestürzt" den genau, ist vorher etwa die Anwendung komplett abgeraucht?
Wenn vorher die Applikation auf den SH's abgeraucht ist, dann ist glaube ich weniger deren (v)CPU's, sondern eher der (v)RAM das Problem.
Gruss Alex
Das ist ja nun auch wiederum auch nicht 100% korrekt.
Im Kern geht es mir schon um Single-Core-Performance, weil die Anwendung eben nur 1 Kern nutzt. Nur sind wir ja nicht bei "wünsch' dir was", sondern bei "so ist es".
Im Kern geht es mir schon um Single-Core-Performance, weil die Anwendung eben nur 1 Kern nutzt. Nur sind wir ja nicht bei "wünsch' dir was", sondern bei "so ist es".
wir meinen schon dasselbe, wir schauen nur von unterschiedlichen Seiten darauf. 😉
Konkrekt geht es mir um die in einer Cloud erreichbare (planungssichere) Performance auf einem Core.
Weil da eben viel Load von der Seite einprasselt auf die CPU:
Weil da eben viel Load von der Seite einprasselt auf die CPU:
- von anderen Subscriptions
- innerhalb von meiner Terminalserver-VM von parallelen Sessions
Na ja, die theoretisch möglich und die dauerhaft verfügbare Performance, ist in der Wolke eben nicht einfach zu kalkulieren, da auf den entsprechenden Nodes im Normallfall ja nicht nur euere VM's, sondern auch die von vielen anderen mitlaufen, daher kann man bei so einem Konstrukt eine hohe Singlethreadleistung meist auch eher knicken.
Zudem verwendet Microsoft in seinen Rechenzentren auch nicht gerade die CPU's, die einen ordentliche Singlethreadperformance liefern.
So wie ich sehe, verwenden die bei Dv5 oder Dsv5 entweder den 8370C oder 8473C Xeons.
Das sind jedoch beides CPU's die mit ihren =>52 Kernen eher dafür ausgelegt sind, parallel soviel Tasks wie möglich, aber nicht wirklich eine bestimmten Task so schnell wie möglich auszuführen. 😔
Da bei den meisten Anwendungen unserer Kunden die Singlethreadleistung auch sehr wichtig ist, verwenden wir bei neuen Systemen z.B. fast nur die folgenden CPU's ...
https://ark.intel.com/content/www/us/en/ark/products/237569/intel-xeon-g ...
... weil die selbst unter Last nicht unter 3,6 GHz einknicken. 😁
Die von MS verwendeten CPU's, können bei Last jedoch auf ~2GHz oder im schlimmsten Fall auch darunter einbrechen. 😔
Wir sind ein gutes Stück weiter gekommen:
Es ist nichts abgestürzt und kam maximal zu kleineren Stalls für 2-3 Sekunden.
Es ist nichts abgestürzt und kam maximal zu kleineren Stalls für 2-3 Sekunden.
Was heisst den "Es ist nichts abgestürzt" den genau, ist vorher etwa die Anwendung komplett abgeraucht?
Diese VMs sind preislich auch so akzeptabel, ich kann da gut mit skalieren wenn wir in den nächsten Wochen doch noch in Probleme rein laufen.
Wenn vorher die Applikation auf den SH's abgeraucht ist, dann ist glaube ich weniger deren (v)CPU's, sondern eher der (v)RAM das Problem.
Gruss Alex
Zitat von @mzurhorst:
Im Kern geht es mir schon um Single-Core-Performance, weil die Anwendung eben nur 1 Kern nutzt.
Moin,Im Kern geht es mir schon um Single-Core-Performance, weil die Anwendung eben nur 1 Kern nutzt.
dann solltest du Hyperthreading für deine VMs abschalten, wie das geht steht hier.
/Thomas
Moin Marcus,
dann hat euer Problem, meiner Erfahrung nach primär nicht wirklich etwas mit den CPU's, sondern eher mit zu wenig vRAM zu tun.
Denn, dass eine Anwendung wegen zu geringen CPU Ressourcen crasht, erlebe ich ehrlich gesagt extrem selten, wenn das der Fall ist, also wenn zu wenig CPU, dann laufen die Anwendungen eben extrem lahm, crashen im normallfall aber nicht wirklich. Mit Anwendungsabstürzen wegen zu geringem RAM, habe ich hingegen leider sehr oft zu tun, Tendenz steigend. 😔
Die CPU's wirst du in einem MS Rechenzentrum wahrscheinlich nicht finden, da sich für MS deren Betrieb nicht wirklich rechnet, respektive, weil MS nicht den gleichen Gewinn damit erwirtschaften kann wie den 8370C oder 8473C Xeons, da man mit den 6544Y Xeon's auf derselben HE Fläche, deutlich weniger VM's betreiben kann.
Der Termin dürfte jetzt ja schon gelaufen sein, ist dabei etwas herausgekommen?
Gruss Alex
Tatsächlich konnten wir bei Load-Tests auf der DC4v2 die Anwendung hart crashen lassen.
Aber die DC-Serie ist deshalb raus geflogen, weil wir einerseits die theoretischen GHz nicht zu Gesicht bekamen, und sie gleichzeitig nur 16GB RAM hatte. Also ja, der (v)RAM ist auch entscheidend.
Aber die DC-Serie ist deshalb raus geflogen, weil wir einerseits die theoretischen GHz nicht zu Gesicht bekamen, und sie gleichzeitig nur 16GB RAM hatte. Also ja, der (v)RAM ist auch entscheidend.
dann hat euer Problem, meiner Erfahrung nach primär nicht wirklich etwas mit den CPU's, sondern eher mit zu wenig vRAM zu tun.
Denn, dass eine Anwendung wegen zu geringen CPU Ressourcen crasht, erlebe ich ehrlich gesagt extrem selten, wenn das der Fall ist, also wenn zu wenig CPU, dann laufen die Anwendungen eben extrem lahm, crashen im normallfall aber nicht wirklich. Mit Anwendungsabstürzen wegen zu geringem RAM, habe ich hingegen leider sehr oft zu tun, Tendenz steigend. 😔
Danke für die Xeon Gold 6544Y, ich mache mich mal auf die Suche nach einem SKU, welches diese CPU in der Region West-Europe anbietet.
Die CPU's wirst du in einem MS Rechenzentrum wahrscheinlich nicht finden, da sich für MS deren Betrieb nicht wirklich rechnet, respektive, weil MS nicht den gleichen Gewinn damit erwirtschaften kann wie den 8370C oder 8473C Xeons, da man mit den 6544Y Xeon's auf derselben HE Fläche, deutlich weniger VM's betreiben kann.
Ich habe aber nächste Woche 2 Azure-Techniker im Haus zu einem Workshop parallel zu unserem Go-Live. Da kann ich das konkret besprechen.
Der Termin dürfte jetzt ja schon gelaufen sein, ist dabei etwas herausgekommen?
Gruss Alex