28
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 93714879627
Url: https://administrator.de/contentid/93714879627
Ausgedruckt am: 21.11.2024 um 23:11 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.
2
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
3
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
2
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
2
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.
4
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.
1
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
Danke euch.
Die Kosten sind erst mal zweitrangig.
Wir haben in den letzten zwei Jahren z.B. zwei mal gezittert, weil uns nach Starkregen plötzlich die Ruhr fast im Rechenzentrum drin stand, nachdem jahrzehntelang der Fluss keine Rolle gespielt hat bei der Bewertung der Sicherheit.
Es gibt so viele Faktoren, die auch on-premise eingepreist werden müssten ....
Wir haben in Amsterdam mit FX4 SKUs begonnen, allerdings steht plötzlich die im genehmigten Quota Request zugesagte Menge nicht mehr zur Verfügung.
Nun sind wir aktuell auf der DC4v2, das wirkt aber eher wie ein Kompromiss, denn hier ist der RAM knapp. Diese Cores sind zumindest ausreichend vorhanden, so dass ich im Sommer das Leasing der Racks auslaufen lassen kann. Ob wir aber dauerhaft dabei bleiben, da bin ich mir halt nicht sicher.
Unser Solution Architect von MS konzentriert sich bei der Suche zur Zeit fast ausschließlich auf die hohe Singe-Core-Performance. Das schränkt die Suche aber sehr stark ein, da wir am Ende ca. 250-270 Terminalserver virtualisieren müssen.
Es fühlt sich sehr faszinierend an, dass wir mit unserer kleinen Anwendung die physischen Grenzen der Cloud gefunden haben. Habe mit vielem gerechnet, aber damit nun nicht.
Die Kosten sind erst mal zweitrangig.
Wir haben in den letzten zwei Jahren z.B. zwei mal gezittert, weil uns nach Starkregen plötzlich die Ruhr fast im Rechenzentrum drin stand, nachdem jahrzehntelang der Fluss keine Rolle gespielt hat bei der Bewertung der Sicherheit.
Es gibt so viele Faktoren, die auch on-premise eingepreist werden müssten ....
Wir haben in Amsterdam mit FX4 SKUs begonnen, allerdings steht plötzlich die im genehmigten Quota Request zugesagte Menge nicht mehr zur Verfügung.
Nun sind wir aktuell auf der DC4v2, das wirkt aber eher wie ein Kompromiss, denn hier ist der RAM knapp. Diese Cores sind zumindest ausreichend vorhanden, so dass ich im Sommer das Leasing der Racks auslaufen lassen kann. Ob wir aber dauerhaft dabei bleiben, da bin ich mir halt nicht sicher.
Unser Solution Architect von MS konzentriert sich bei der Suche zur Zeit fast ausschließlich auf die hohe Singe-Core-Performance. Das schränkt die Suche aber sehr stark ein, da wir am Ende ca. 250-270 Terminalserver virtualisieren müssen.
Es fühlt sich sehr faszinierend an, dass wir mit unserer kleinen Anwendung die physischen Grenzen der Cloud gefunden haben. Habe mit vielem gerechnet, aber damit nun nicht.
1
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
Moin.
Die Latenz innerhalb von Azure zwischen Terminalserver, DB-Server und File Server haben wir mit Proximity Groups ganz gut optimieren können.
Allerdings haben wir hier auch gerade festgestellt, dass wir beim Wechsel der SKUs (wir hatten mehrere gestestet) dann z.B. die Proximity Group plötzlich nicht mehr konfigurieren können. (vermutlich, weil da die verschiedenen SKUs auch über mehrere Gebäude auf dem Gelände verteilt sind)
Die Verbindung von der Firma aus in die Azure-Cloud hat eine Express Route. Hier haben wir auch mit AT&T, ZScaler etc. die Routing geprüft und optimiert. Diese Latenz tut uns nicht so weh bei der Benutzung der Software auf dem Terminalserver, wir merken es "nur" wenn wir Daten verschieben. Das ist aber verkraftbar.
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.
Das geht aber vom Thema ab.
Mich interessierte eigentlich nur, ob meine Hypothese berechtigt sei, dass die max. erreichbare Single-Core-Last bei Azure mit großer Wahrscheinlichkeit nur eine theoretische Größe auf dem Papier wäre.
==> Da habe ich für mich mitgenommen, dass meine Annahme korrekt ist.
Danke und viele Grüße,
Marcus
Die Latenz innerhalb von Azure zwischen Terminalserver, DB-Server und File Server haben wir mit Proximity Groups ganz gut optimieren können.
Allerdings haben wir hier auch gerade festgestellt, dass wir beim Wechsel der SKUs (wir hatten mehrere gestestet) dann z.B. die Proximity Group plötzlich nicht mehr konfigurieren können. (vermutlich, weil da die verschiedenen SKUs auch über mehrere Gebäude auf dem Gelände verteilt sind)
Die Verbindung von der Firma aus in die Azure-Cloud hat eine Express Route. Hier haben wir auch mit AT&T, ZScaler etc. die Routing geprüft und optimiert. Diese Latenz tut uns nicht so weh bei der Benutzung der Software auf dem Terminalserver, wir merken es "nur" wenn wir Daten verschieben. Das ist aber verkraftbar.
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.
Das geht aber vom Thema ab.
Mich interessierte eigentlich nur, ob meine Hypothese berechtigt sei, dass die max. erreichbare Single-Core-Last bei Azure mit großer Wahrscheinlichkeit nur eine theoretische Größe auf dem Papier wäre.
==> Da habe ich für mich mitgenommen, dass meine Annahme korrekt ist.
Danke und viele Grüße,
Marcus
1Zitat 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
Ja und nein.
Ich denke, dass wir insgesamt zu langsam sind. Mein Team macht im Grunde nur IT Service für die Applikation. Dieses Cloud-Projekt geht als Hobby "on top", und wir mussten uns viel Wissen selbst erarbeiten.
Ich gehe davon aus, dass andere Kunden uns die im Quota Request zugesicherten VMs weggeschnappt haben, da sie schneller skalieren konnten als wir. (ist ja auch logisch, nur mit laufenden VMs verdient MS Geld)
Wir planen auf jeden Fall, einen größeren Teil der PROD-Umgebung 24/7 laufen zu haben, und dann die 3-Jahre-Reservierung zu ziehen.
Aber: selbst unser MS Consultant rät uns von 100% Reservation ab. Ich habe z.B. Master-Server, die wir nur 2-3x im Monat benötigen für OS-Patching und Anpassungen an der Software-Lösung. Die werden hochgefahren, modifiziert, und fahren direkt wieder runter. Maximal 20h im Monat. Dann wird das Disk-Image gezogen, und die Terminalserver müssen 1x rebooten.
==> Für diese Server ist die Reservation sehr teuer und lohnt sich nicht.
Über unser Enterprise Agreement schaut es in etwa so aus:
Die spannenden Fragen für die nächsten Monate wird sein:
Ich denke, dass wir insgesamt zu langsam sind. Mein Team macht im Grunde nur IT Service für die Applikation. Dieses Cloud-Projekt geht als Hobby "on top", und wir mussten uns viel Wissen selbst erarbeiten.
Ich gehe davon aus, dass andere Kunden uns die im Quota Request zugesicherten VMs weggeschnappt haben, da sie schneller skalieren konnten als wir. (ist ja auch logisch, nur mit laufenden VMs verdient MS Geld)
Wir planen auf jeden Fall, einen größeren Teil der PROD-Umgebung 24/7 laufen zu haben, und dann die 3-Jahre-Reservierung zu ziehen.
Aber: selbst unser MS Consultant rät uns von 100% Reservation ab. Ich habe z.B. Master-Server, die wir nur 2-3x im Monat benötigen für OS-Patching und Anpassungen an der Software-Lösung. Die werden hochgefahren, modifiziert, und fahren direkt wieder runter. Maximal 20h im Monat. Dann wird das Disk-Image gezogen, und die Terminalserver müssen 1x rebooten.
==> Für diese Server ist die Reservation sehr teuer und lohnt sich nicht.
Über unser Enterprise Agreement schaut es in etwa so aus:
- 24/7 mit Reservation als Baseline
- 24/7 im PAYG ist dann 55% teurer
- 370h Betrieb ist etwa gleich teuer
- ... je weiter darunter, desto günstiger
Die spannenden Fragen für die nächsten Monate wird sein:
- Wie verlässlich können wir die nicht reservierten Ressourcen booten?
- Wie sehr können wir den Load Balancer an unsere Bedürfnisse anpassen, um die Kosten zu drücken?
1
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
1
Hi Stefan,
danke für die Info.
Es handelt sich bei der Anwendung um COMOS, eine Plant Engineering Software von Siemens PLM. Wir haben da keine Hebel, außer immer wieder eine Neuerung anzufordern. Die haben aber aktuell noch dringendere Altlasten zu beheben, würde ich sagen.
Hetzner etc. stellt für uns keine Option da. Wir sind als großes Enterprise an Vorgaben aus dem Konzern gebunden. Daher gibt es ausschließlich Azure oder GCP zur "Auswahl".
Ich muss bis Ende Mai sowohl Citrix als auch HW Leasing verlängern, wir haben den Projektpuffer (auch) aufgrund der Verfügbarkeitsprobleme mit den FX4 SKUs komplett verbraten.
Egal ob ich innerhalb von Azure das RZ wechsele, oder ob ich den Provider wechsele, ich bin dann auf jeden Fall tot.
Daher bleibt es jetzt bei "West Europe". Die Performance kann ich ganz gut ausbalancieren, in dem ich die Zahl der Sessions pro Host reduziere.
Wir suchen parallel weiter nach anderen SKUs. Vor 1h kam die Meldung rein, dass wir wohl mit der "D8ds_v5" ganz gut dastehen von der Performance her.
Die Single-Core-Performance ist mMn. genau nicht mein Problem, würde ich sagen. Die wäre nur relevant, wenn der User unter dem Tisch eine Workstation stehen hätte.
Eine maximal hohe, garantierte Multi-Core-Performance scheint mir deutlich mehr Planungssicherung zu geben.
Darum geht es ja im Kern meiner ursprünglichen Frage.
VG, Marcus
danke für die Info.
Es handelt sich bei der Anwendung um COMOS, eine Plant Engineering Software von Siemens PLM. Wir haben da keine Hebel, außer immer wieder eine Neuerung anzufordern. Die haben aber aktuell noch dringendere Altlasten zu beheben, würde ich sagen.
Hetzner etc. stellt für uns keine Option da. Wir sind als großes Enterprise an Vorgaben aus dem Konzern gebunden. Daher gibt es ausschließlich Azure oder GCP zur "Auswahl".
Ich muss bis Ende Mai sowohl Citrix als auch HW Leasing verlängern, wir haben den Projektpuffer (auch) aufgrund der Verfügbarkeitsprobleme mit den FX4 SKUs komplett verbraten.
Egal ob ich innerhalb von Azure das RZ wechsele, oder ob ich den Provider wechsele, ich bin dann auf jeden Fall tot.
Daher bleibt es jetzt bei "West Europe". Die Performance kann ich ganz gut ausbalancieren, in dem ich die Zahl der Sessions pro Host reduziere.
Wir suchen parallel weiter nach anderen SKUs. Vor 1h kam die Meldung rein, dass wir wohl mit der "D8ds_v5" ganz gut dastehen von der Performance her.
Die Single-Core-Performance ist mMn. genau nicht mein Problem, würde ich sagen. Die wäre nur relevant, wenn der User unter dem Tisch eine Workstation stehen hätte.
Eine maximal hohe, garantierte Multi-Core-Performance scheint mir deutlich mehr Planungssicherung zu geben.
Darum geht es ja im Kern meiner ursprünglichen Frage.
VG, Marcus
1
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. 🤪
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
Zitat von @MysticFoxDE:
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. 😔
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. 😔
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".
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:
- von anderen Subscriptions
- innerhalb von meiner Terminalserver-VM von parallelen Sessions
)Wir sind ein gutes Stück weiter gekommen:
Wir haben nun eine D8ds_v5 (8x 2.8GHz Xeon, 32GB RAM) konfiguriert, und konnten damit mit 11 angemeldeten Sessions und 11x COMOS gestartet darauf noch arbeiten. COMOS ist noch 32bit, daher passte das gut in dem RAM rein, selbst wenn wir parallel heftigere Operationen in verschiedenen Sessions hatten.
Es ist nichts abgestürzt und kam maximal zu kleineren Stalls für 2-3 Sekunden.
Für das Sizing des Environments gehen wir nun erst mal von 10 Sessions aus. Manche User navigieren nur durch die Software, andere sind im Meeting oder der Pause, es werden voraussichtlich nie alle 10 Sessions gleichzeitig einen Super-GAU provozieren.
Damit gibt es nächste Woche den ersten Go-Live, und dann schauen wir mal weiter.
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.
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
Hi 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.
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.
Sollte bei der D8ds_v5 die Frequenz noch deutlich unter die 2.8GHz fallen, sind wir nämlich dann auch wieder gekniffen.
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.
Mein Vorteil: ich habe 11 unterschiedliche Environments in Summe, mit unterschiedlichen Auslastungen, Ansprüchen etc. Es muss nicht jeder das gleiche SKU verwenden. Dank Terraform etc. sind wir extrem flexibel. Es ist nur gewöhnungsbedürftig, weil das Vorgehen lokal immer ein anderes war.
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.
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.
Sollte bei der D8ds_v5 die Frequenz noch deutlich unter die 2.8GHz fallen, sind wir nämlich dann auch wieder gekniffen.
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.
Mein Vorteil: ich habe 11 unterschiedliche Environments in Summe, mit unterschiedlichen Auslastungen, Ansprüchen etc. Es muss nicht jeder das gleiche SKU verwenden. Dank Terraform etc. sind wir extrem flexibel. Es ist nur gewöhnungsbedürftig, weil das Vorgehen lokal immer ein anderes war.
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
