26
I7 12700K vs Xeon Gold 6246
Hallo an alle,
heute wende ich mich mal wieder mit einem kleinen Problem an mein Lieblings Forum.
Meine Firma hat eine Software entwickelt die einen Web und SQL Server benötigt.
Der Web Server wird unter Ubuntu Server und der MSSQL Server unter Windows Server 2022 DC ausgeführt.
Hier mal die Serverhardware, die wir bei einem Kunden einsetzen.
Die Festplatten für DB, TempDB und LOG werden nicht direkt an die MSSQL VM durchgereicht.
Das sollte sich allerdings nicht spürbar auf die Performance auswirken.
Aber um den I/O Load geht es eigentlich nicht.
Es geht rein um CPU.
Wir streiten seit letzter Woche mit einem unserer Developer.
Es testet unserer Software auf seinem Notebook mit einem i7-12700K
Er ist der Meinung, sein Notebook ist schneller als unser beim Kunden eingesetzter Server.
Benchmarken tut er seine CPU unter Linux mit sysbench.
Sein Test mit:
ergibt 4012.6 Events per Second
Mit 100 Threads:
kommt er auf 46437.73Events per Second
Er testet natürlich mit allen Cores - nativ.
Ich teste die Linux VM mit 16 Cores.
Mein Test mit dem Xeon Gold kommt mit
auf 1289.76 Events per Second
und mit
komme ich auf 41060 Events per Second
Jetzt wurde extra ein HyperV Experte beauftragt, sich den Server genauer anzusehen.
Dieser ist seit letzten Donnerstag auf dem Server und macht sein Ding.
Einen ersten Bericht haben wir bereits von ihm bekommen. Diesen kann ich hier als Bild einstellen wenn es relevant ist.
User Developer redet immer von SingelCore Performance. Diese interessiert mich aber nicht.
Unsere Software profitiert von MultiCore Performance.
Seit dieser Server bei dem Kunden im Einsatz ist, gibt es keinerlei Beschwerden mehr von den Benutzern wegen der Geschwindigkeit.
Nur unser Developer hängt uns in den Ohren.
Ich denke, das an der falschen Stelle gesucht wird.
Meiner Meinung nach sollte man mal ein Auge auf die SQL Abfragen und die Indices werfen.
Kann man überhaupt ein Notebook mit einem Server im Bezug auf eine Server Anwendung, so wie es unser Developer tut, vergleichen?
Ist der Server, den ich zusammengestellt habe, nicht gut genug?
Der HyperV Spezi. konnte bis jetzt jedenfalls nichts finden.
Sollte der Bericht vom Spezi relevant sein, bitte sagen. Dann poste ich ihn.
LG
Chris
heute wende ich mich mal wieder mit einem kleinen Problem an mein Lieblings Forum.
Meine Firma hat eine Software entwickelt die einen Web und SQL Server benötigt.
Der Web Server wird unter Ubuntu Server und der MSSQL Server unter Windows Server 2022 DC ausgeführt.
Hier mal die Serverhardware, die wir bei einem Kunden einsetzen.
Prozessoren - CPU: 2 x Intel Xeon Gold 6246 SRFPJ 12C Server Prozessor 12x 3,30 GHz 24,75MB Cache 3647 CPU
Arbeitsspeicher - RAM: 512GB Registered ECC DDR4 SDRAM (16x 32GB DIMM)
Main Storage Adapter - HP Smart Array P408i-a SR Gen10 2GB Cache 8-Port modular Raid Controller im HBA Mode
Solid State Disk Datenträger - 6 x 960GB 2,5" Samsung PM1643a Datacenter Enterprise 24/7 Industrial 12G SAS SSD 380K
Davon immer 2 im GRAID - RAID1 für DB Logs, TempDB und Application
NVMe PCIe Datenträger - 2 x 960GB Samsung PM9A3 Datacenter Enterprise 24/7 SFF 2,5" U.2 NVMe PCIe Gen4 1000K IOPS
Beide im GRAID - RAID1 für DB Files
6 x 1,92TB Samsung PM9A3 Datacenter Enterprise 24/7 SFF 2,5" U.2
Im GRAID - RAID5 + HotSpare
1 x HP NS204i-p PCIe x8 NVMe 2x 480GB M.2 Controller
Dort ist das OS installiertDie Festplatten für DB, TempDB und LOG werden nicht direkt an die MSSQL VM durchgereicht.
Das sollte sich allerdings nicht spürbar auf die Performance auswirken.
Aber um den I/O Load geht es eigentlich nicht.
Es geht rein um CPU.
Wir streiten seit letzter Woche mit einem unserer Developer.
Es testet unserer Software auf seinem Notebook mit einem i7-12700K
Er ist der Meinung, sein Notebook ist schneller als unser beim Kunden eingesetzter Server.
Benchmarken tut er seine CPU unter Linux mit sysbench.
Sein Test mit:
sysbench cpu runergibt 4012.6 Events per Second
Mit 100 Threads:
sysbench cpu --threads=100 runEr testet natürlich mit allen Cores - nativ.
Ich teste die Linux VM mit 16 Cores.
Mein Test mit dem Xeon Gold kommt mit
sysbench cpu runund mit
sysbench cpu --threads=100 runJetzt wurde extra ein HyperV Experte beauftragt, sich den Server genauer anzusehen.
Dieser ist seit letzten Donnerstag auf dem Server und macht sein Ding.
Einen ersten Bericht haben wir bereits von ihm bekommen. Diesen kann ich hier als Bild einstellen wenn es relevant ist.
User Developer redet immer von SingelCore Performance. Diese interessiert mich aber nicht.
Unsere Software profitiert von MultiCore Performance.
Seit dieser Server bei dem Kunden im Einsatz ist, gibt es keinerlei Beschwerden mehr von den Benutzern wegen der Geschwindigkeit.
Nur unser Developer hängt uns in den Ohren.
Ich denke, das an der falschen Stelle gesucht wird.
Meiner Meinung nach sollte man mal ein Auge auf die SQL Abfragen und die Indices werfen.
Kann man überhaupt ein Notebook mit einem Server im Bezug auf eine Server Anwendung, so wie es unser Developer tut, vergleichen?
Ist der Server, den ich zusammengestellt habe, nicht gut genug?
Der HyperV Spezi. konnte bis jetzt jedenfalls nichts finden.
Sollte der Bericht vom Spezi relevant sein, bitte sagen. Dann poste ich ihn.
LG
Chris
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: 669238
Url: https://administrator.de/contentid/669238
Ausgedruckt am: 23.11.2024 um 09:11 Uhr
26 Kommentare
Neuester Kommentar
Moin, also erstmal hat der Server ne 5 Jahre alte CPU, falls der irgendwann in den letzten Jahren angeschafft wurde hat da jemand aber echt gepennt...
1
Das ist bekannt. Danke.
Sind beides 12-Kerner, wobei der I7 höher taktet als der Xeon.
Der I7 ist schneller.
https://www.cpu-monkey.com/en/compare_cpu-intel_xeon_gold_6246-vs-intel_ ...
Aber halt auch jetzt keine riesigen Unterschiede.
IMHO kommts drauf an, was da genau gemacht wird, wann wieviele Kerne oder Threads verwendet werden und wie die Datenbank und Gekröse angeflanscht ist.
Der I7 ist schneller.
https://www.cpu-monkey.com/en/compare_cpu-intel_xeon_gold_6246-vs-intel_ ...
Aber halt auch jetzt keine riesigen Unterschiede.
IMHO kommts drauf an, was da genau gemacht wird, wann wieviele Kerne oder Threads verwendet werden und wie die Datenbank und Gekröse angeflanscht ist.
Der i7 12700 müsste 14 Cores haben laut Datenblatt.
Die Software ist mit 4vCPU's genauso schnell wie mit 16 vCPU's auf dem Server.
Ich kann keine signifikanten Unterschiede an der Performance feststellen.
Kurz zur Software: Unserer Software ist das "SAP" der Landwirte.
Die Software ist mit 4vCPU's genauso schnell wie mit 16 vCPU's auf dem Server.
Ich kann keine signifikanten Unterschiede an der Performance feststellen.
Kurz zur Software: Unserer Software ist das "SAP" der Landwirte.
Interessantes Datenblatt das ihr da habt
https://www.intel.de/content/www/de/de/products/sku/134594/intel-core-i7 ...
Aber: zwei Kerne hin oder her, wenn diese Software 14 Kerne braucht und mit 12 nicht vernünftig arbeitet, tjoa....
Die Software kenne ich, denke ich. Und sorry, der Vergleich mit SAP stimmt.
https://www.intel.de/content/www/de/de/products/sku/134594/intel-core-i7 ...
Aber: zwei Kerne hin oder her, wenn diese Software 14 Kerne braucht und mit 12 nicht vernünftig arbeitet, tjoa....
Die Software kenne ich, denke ich. Und sorry, der Vergleich mit SAP stimmt.
Es kommt ja erst mal auf die Anzahl der User an, die mit dem System arbeiten.
Damit will ich sagen, der VM sind zurzeit 4vCPU's zugeteilt.
Edit: Diese sind nicht mal zu 10% ausgelastet. Heißt: Auch wenn ich der VM 16 Cores gebe wird die Software mit der gleichen Anzahl an Benutzern, nicht spürbar schneller.
Kann sie ja auch nicht.
Sorry, Hab nach dem 12700H geschaut.
Damit will ich sagen, der VM sind zurzeit 4vCPU's zugeteilt.
Edit: Diese sind nicht mal zu 10% ausgelastet. Heißt: Auch wenn ich der VM 16 Cores gebe wird die Software mit der gleichen Anzahl an Benutzern, nicht spürbar schneller.
Kann sie ja auch nicht.
Sorry, Hab nach dem 12700H geschaut.
Hallo,
ich würde mich da deiner Meinung anschließen.
Ein Server soll ja keine Benchmarks befriedigen, sondern real benötigte Leistung erbringen.
Sinniger Test wäre z.B. ein identischer Prozess (Tagesabschluss oder was es da gibt) zu starten und zu vergleichen
Sowohl am Hypervisor als auch bei den VMs kann man das ein oder andere Schräubchen drehen, um noch paar Prozent herauszuholen.
BIOS und VM > High Performance Profile etc, ALUA, ...
Dennoch wird man bei einer VM nie ganz an Baremetal Leistung herankommen. Dafür gewinnt man aber deutlich an Flexibilität und Verfügbarkeit.
Viel Erfolg von einem Leidgenossen
ich würde mich da deiner Meinung anschließen.
Ein Server soll ja keine Benchmarks befriedigen, sondern real benötigte Leistung erbringen.
Sinniger Test wäre z.B. ein identischer Prozess (Tagesabschluss oder was es da gibt) zu starten und zu vergleichen
Sowohl am Hypervisor als auch bei den VMs kann man das ein oder andere Schräubchen drehen, um noch paar Prozent herauszuholen.
BIOS und VM > High Performance Profile etc, ALUA, ...
Dennoch wird man bei einer VM nie ganz an Baremetal Leistung herankommen. Dafür gewinnt man aber deutlich an Flexibilität und Verfügbarkeit.
Viel Erfolg von einem Leidgenossen
1
Danke für eure Beiträge.
Ist alles korrekt eingestellt.
Aber du hast natürlich auch recht.
Die Zahlen vom Benchmark sind relativ irrelevant.
Es sollte mit einem Workload in der Software getestet werden.
Wie du schon sagtest, mit einem Abschluss.
BIOS und VM > High Performance Profile etc, ALUA, ...
Ist alles korrekt eingestellt.
Aber du hast natürlich auch recht.
Die Zahlen vom Benchmark sind relativ irrelevant.
Es sollte mit einem Workload in der Software getestet werden.
Wie du schon sagtest, mit einem Abschluss.
Du bekommst auch ein signifikantes Problem wenn du in einem Hypervisor, egal welcher Couleur, einer einzelnen VM die selbe Anzahl an vCores zuweist, wie du physisch zur Verfügung hast. Selbst wenn alle anderen VMs nicht laufen, braucht zumindest der Hypervisor selbst zwischendurch mal Rechenzeit. In dem Takt, wo der Hypervisor dann rechnet, rechnet deine VM nicht! - Sie muss dann warten bis sie an der Reihe ist - Den immer wenn sie rechnet braucht sie auch alle Kerne, die du zugeteilt hast. Du kannst also mit einer zu hohen Zuweisung deine Performance schnell verschlechtern.
1
Danke für deinen Beitrag. Dessen bin ich mir absolut bewusst.
Auch das es bei Virtualisierung manchmal heißt: weniger ist schneller.
LG
Auch das es bei Virtualisierung manchmal heißt: weniger ist schneller.
LG
Zitat von @ukulele-7:
Du bekommst auch ein signifikantes Problem wenn du in einem Hypervisor, egal welcher Couleur, einer einzelnen VM die selbe Anzahl an vCores zuweist, wie du physisch zur Verfügung hast. Selbst wenn alle anderen VMs nicht laufen, braucht zumindest der Hypervisor selbst zwischendurch mal Rechenzeit. In dem Takt, wo der Hypervisor dann rechnet, rechnet deine VM nicht! - Sie muss dann warten bis sie an der Reihe ist - Den immer wenn sie rechnet braucht sie auch alle Kerne, die du zugeteilt hast. Du kannst also mit einer zu hohen Zuweisung deine Performance schnell verschlechtern.
Du bekommst auch ein signifikantes Problem wenn du in einem Hypervisor, egal welcher Couleur, einer einzelnen VM die selbe Anzahl an vCores zuweist, wie du physisch zur Verfügung hast. Selbst wenn alle anderen VMs nicht laufen, braucht zumindest der Hypervisor selbst zwischendurch mal Rechenzeit. In dem Takt, wo der Hypervisor dann rechnet, rechnet deine VM nicht! - Sie muss dann warten bis sie an der Reihe ist - Den immer wenn sie rechnet braucht sie auch alle Kerne, die du zugeteilt hast. Du kannst also mit einer zu hohen Zuweisung deine Performance schnell verschlechtern.
Das stimmt, zumindest für hyper-v, nicht.
1
Sollte aber für den RAM gelten.
Zitat von @pebcak7123:
Das stimmt, zumindest für hyper-v, nicht.
Zitat von @ukulele-7:
Du bekommst auch ein signifikantes Problem wenn du in einem Hypervisor, egal welcher Couleur, einer einzelnen VM die selbe Anzahl an vCores zuweist, wie du physisch zur Verfügung hast. Selbst wenn alle anderen VMs nicht laufen, braucht zumindest der Hypervisor selbst zwischendurch mal Rechenzeit. In dem Takt, wo der Hypervisor dann rechnet, rechnet deine VM nicht! - Sie muss dann warten bis sie an der Reihe ist - Den immer wenn sie rechnet braucht sie auch alle Kerne, die du zugeteilt hast. Du kannst also mit einer zu hohen Zuweisung deine Performance schnell verschlechtern.
Du bekommst auch ein signifikantes Problem wenn du in einem Hypervisor, egal welcher Couleur, einer einzelnen VM die selbe Anzahl an vCores zuweist, wie du physisch zur Verfügung hast. Selbst wenn alle anderen VMs nicht laufen, braucht zumindest der Hypervisor selbst zwischendurch mal Rechenzeit. In dem Takt, wo der Hypervisor dann rechnet, rechnet deine VM nicht! - Sie muss dann warten bis sie an der Reihe ist - Den immer wenn sie rechnet braucht sie auch alle Kerne, die du zugeteilt hast. Du kannst also mit einer zu hohen Zuweisung deine Performance schnell verschlechtern.
Das stimmt, zumindest für hyper-v, nicht.
Das wage ich zu bezweifeln.
@ukulele-7:
Recht so! Denn die Best Practice für Hyper-V besagen meiner Erinnerung nach, dass für das Hyper-V-BS immer ein, besser zwei Kerne belassen werden sollen. Bei einer Überprovisionierung - also mehr vCPU's als physische/logische Kerne werden zugewiesen - zwingt das jederzeit zu Wartezeiten bei der Rechenzeitverteilung. In vollgestopften Hyper-V-Host natürlich eine unvermeidbare Folge.
Solange ich einen Hyper-V benutzt habe, konnte ich den Leistungsverlust bei solchen Wartezeiten durchaus wahrnehmen. Daher habe ich immer darauf geachtet, eine Überprovisionierung zu vermeiden. Zeitkritische VM's wie Datenbanken, Telefonanlage etc. danken es.
Eine zweite Regel ist, immer nur ganzzahlige Teiler an vCPU's zuzuweisen - also: 1, 2, 4, 8 ... So ist es dem Hypervisor möglich, wenn beispielsweise zwei vCPU's von einer VM "freigemacht" werden, diese auf zwei VM's mit jeweils nur einer vCPU zu verteilen, was wiederum die Leistung auf dem Host insgesamt verbessert.
Zudem ist kritisch zu hinterfragen, wieviele vCPU's pro VM wirklich gebraucht werden. Viel hilft viel, ist hier völlig deplatziert.
Viele Grüße
HansDampf06
Recht so! Denn die Best Practice für Hyper-V besagen meiner Erinnerung nach, dass für das Hyper-V-BS immer ein, besser zwei Kerne belassen werden sollen. Bei einer Überprovisionierung - also mehr vCPU's als physische/logische Kerne werden zugewiesen - zwingt das jederzeit zu Wartezeiten bei der Rechenzeitverteilung. In vollgestopften Hyper-V-Host natürlich eine unvermeidbare Folge.
Solange ich einen Hyper-V benutzt habe, konnte ich den Leistungsverlust bei solchen Wartezeiten durchaus wahrnehmen. Daher habe ich immer darauf geachtet, eine Überprovisionierung zu vermeiden. Zeitkritische VM's wie Datenbanken, Telefonanlage etc. danken es.
Eine zweite Regel ist, immer nur ganzzahlige Teiler an vCPU's zuzuweisen - also: 1, 2, 4, 8 ... So ist es dem Hypervisor möglich, wenn beispielsweise zwei vCPU's von einer VM "freigemacht" werden, diese auf zwei VM's mit jeweils nur einer vCPU zu verteilen, was wiederum die Leistung auf dem Host insgesamt verbessert.
Zudem ist kritisch zu hinterfragen, wieviele vCPU's pro VM wirklich gebraucht werden. Viel hilft viel, ist hier völlig deplatziert.
Viele Grüße
HansDampf06
1Was ist denn jetzt eigentlich das Problem bzw. welche Frage willst du beantwortet haben?
Moin,
habe da gestern Müll geschrieben.
Ich meinte natürlich nicht ALUA sondern NUMA. (2 von 4 Buchstaben nur getroffen)
Ohne die Applikation genau zu kennen, kann es natürlich extrem kontraproduktiv sein, auf einer 12 Kern CPU eine 16 Core VM laufen zu lassen!
Gruß
habe da gestern Müll geschrieben.
Ich meinte natürlich nicht ALUA sondern NUMA. (2 von 4 Buchstaben nur getroffen)
Ohne die Applikation genau zu kennen, kann es natürlich extrem kontraproduktiv sein, auf einer 12 Kern CPU eine 16 Core VM laufen zu lassen!
Gruß
Hi,
wir haben auch mal "herumgebenchmarkt". In dem Fall aber für eine CAD Software.
Solange das kein spezifischer Benchmark ist hat es relativ wenig Aussagekraft.
Da gabs auch Theorien bezüglich gaming GPU vs Quadro. Die Benschmarks zeigen wilde Unterschiede. Real aber nicht relevant.
Ein Vorteil - den wir bei den Quadros sahen, die kannst du auf 100% auslasten und das über Stunden. Die Gaming GPUs, können per Peaks schneller, aber brauchen ihre Verschnaufpausen.
Und am Ende hatte auch der spezifische Benchmark (Eingaben wurden direkt in der Software simuliert) 10% mit einer bestimmten Hardware ergeben, aber wir haben uns trotzdem nicht für die Highend Hardware entschieden, da in der Praxis noch ein Benutzer vorm PC sitzt...
Sieht man auch etwas an deinen Werten.
Singlecore 4 fache Leistung - da zaubert der i7 wohl mit Turbo / einen Core übertakten. Sobald etwas parallel läuft hustet er wohl los. Wie lang lief der Benchmark?
Multicore, sind es grad mal paar %.
Hast den Developer schon mal gefragt wie er die neue Hardware dem Kunden verkaufen will, wenn der keine Probleme hat?
wir haben auch mal "herumgebenchmarkt". In dem Fall aber für eine CAD Software.
Solange das kein spezifischer Benchmark ist hat es relativ wenig Aussagekraft.
Da gabs auch Theorien bezüglich gaming GPU vs Quadro. Die Benschmarks zeigen wilde Unterschiede. Real aber nicht relevant.
Ein Vorteil - den wir bei den Quadros sahen, die kannst du auf 100% auslasten und das über Stunden. Die Gaming GPUs, können per Peaks schneller, aber brauchen ihre Verschnaufpausen.
Und am Ende hatte auch der spezifische Benchmark (Eingaben wurden direkt in der Software simuliert) 10% mit einer bestimmten Hardware ergeben, aber wir haben uns trotzdem nicht für die Highend Hardware entschieden, da in der Praxis noch ein Benutzer vorm PC sitzt...
Sieht man auch etwas an deinen Werten.
Singlecore 4 fache Leistung - da zaubert der i7 wohl mit Turbo / einen Core übertakten. Sobald etwas parallel läuft hustet er wohl los. Wie lang lief der Benchmark?
Multicore, sind es grad mal paar %.
Hast den Developer schon mal gefragt wie er die neue Hardware dem Kunden verkaufen will, wenn der keine Probleme hat?
Hey,
danke für eure Beiträge.
Ob die Benchmarks die unser Developer durchführt von Relevanz in einem Produktivsystem sind, auf dem unsere Software ausgeführt wird.
Die neue Hardware wurde dem Kunden schon verkauft und ist bereits produktiv im Einsatz. Wurde von mir verkauft.
danke für eure Beiträge.
Was ist denn jetzt eigentlich das Problem bzw. welche Frage willst du beantwortet haben?
Ob die Benchmarks die unser Developer durchführt von Relevanz in einem Produktivsystem sind, auf dem unsere Software ausgeführt wird.
Hast den Developer schon mal gefragt wie er die neue Hardware dem Kunden verkaufen will, wenn der keine Probleme hat?
Die neue Hardware wurde dem Kunden schon verkauft und ist bereits produktiv im Einsatz. Wurde von mir verkauft.
1.) Läuft eure Serveranwendung alleine auf dieser Hardware? Virtualisierung würde in dem Fall einige Nachteile bei der Performance mit sich bringen, sofern du den Workload nicht auf mehrere VMs verteilen kannst. Wir wissen hier nicht mal, was zum Zeitpunkt der Benchmarks noch auf der Hardware lief - im Idealfall sonst nichts. Aber meist wird nicht aus Spaß an der Freude virtualisiert, sondern mit konkreten Zielen.
2.) Profitiert eure Software von einer hohen Single Thread Performance? Vielleicht, wenn z.B. einzelne Komponenten nicht parallelisierbar sind. Also wenn z.B. mehrere Abfragen gleichzeitig laufen können, aber eine Abfrage für sich genommen von der Geschwindigkeit eines einzelnen Threads abhängen. Nur unter solchen Umständen wäre Single Thread theoretisch relevant, je nach Praxis wirkt sich das aber nicht zwingend aus.
Ich sage daher mal, die Benchmarks sind nicht vergleichbar. Bei der nächsten Hardware-Anschaffung machst du vorher mal eine Testreihe, bare metal OS i7 von deinem Entwickler (einfach temporär ne andere SSD rein) vs. bare metal Epyc oder Xeon. Das kann man vergleichen. Dennoch muss man immer 1.) im Hinterkopf haben, sofern nicht das System vor Ort nur für diesen Zweck betrieben wird.
2.) Profitiert eure Software von einer hohen Single Thread Performance? Vielleicht, wenn z.B. einzelne Komponenten nicht parallelisierbar sind. Also wenn z.B. mehrere Abfragen gleichzeitig laufen können, aber eine Abfrage für sich genommen von der Geschwindigkeit eines einzelnen Threads abhängen. Nur unter solchen Umständen wäre Single Thread theoretisch relevant, je nach Praxis wirkt sich das aber nicht zwingend aus.
Ich sage daher mal, die Benchmarks sind nicht vergleichbar. Bei der nächsten Hardware-Anschaffung machst du vorher mal eine Testreihe, bare metal OS i7 von deinem Entwickler (einfach temporär ne andere SSD rein) vs. bare metal Epyc oder Xeon. Das kann man vergleichen. Dennoch muss man immer 1.) im Hinterkopf haben, sofern nicht das System vor Ort nur für diesen Zweck betrieben wird.
Danke ukulele.
Der Server wurde so dimensioniert das unsere Software mit 2 VM's(Web und DB)
und eventuell weitere VM's darauf ausgeführt werden können.
Während des Benchmarks wurden beide VM's(Web und DB) ausgeführt.
Der VM Load betrug während der Benchmarks nicht mal 2% je VM.
Nein, das tut sie nicht.
Es handelt sich um dynamische Daten die angezeigt und verändert werden.
Es werden auch keine komplizierten Berechnungen ausgeführt.
Dem ist nicht so.
Meine Rede.
Hier werden Äpfel mit Birnen verglichen.
Was soll ein Benchmark, das Primzahlen berechnet über die Performance unserer Software aussagen? Unsere Software muss keine Primzahlen berechnen.
Läuft eure Serveranwendung alleine auf dieser Hardware?
Der Server wurde so dimensioniert das unsere Software mit 2 VM's(Web und DB)
und eventuell weitere VM's darauf ausgeführt werden können.
Während des Benchmarks wurden beide VM's(Web und DB) ausgeführt.
Der VM Load betrug während der Benchmarks nicht mal 2% je VM.
Profitiert eure Software von einer hohen Single Thread Performance?
Nein, das tut sie nicht.
Es handelt sich um dynamische Daten die angezeigt und verändert werden.
Es werden auch keine komplizierten Berechnungen ausgeführt.
Also wenn z.B. mehrere Abfragen gleichzeitig laufen können, aber eine Abfrage für sich genommen von der Geschwindigkeit eines einzelnen Threads abhängen.
Dem ist nicht so.
Ich sage daher mal, die Benchmarks sind nicht vergleichbar
Meine Rede.
Hier werden Äpfel mit Birnen verglichen.
Was soll ein Benchmark, das Primzahlen berechnet über die Performance unserer Software aussagen? Unsere Software muss keine Primzahlen berechnen.
Läuft eure Serveranwendung alleine auf dieser Hardware?
Der Server wurde so dimensioniert das unsere Software mit 2 VM's(Web und DB)
und eventuell weitere VM's darauf ausgeführt werden können.
Während des Benchmarks wurden beide VM's(Web und DB) ausgeführt.
Der VM Load betrug während der Benchmarks nicht mal 2% je VM.
Dann ist der Benchmark unfähig, den Server auszulasten?Der VM Load betrug während der Benchmarks nicht mal 2% je VM.
Was soll ein Benchmark, das Primzahlen berechnet über die Performance unserer Software aussagen? Unsere Software muss keine Primzahlen berechnen.
Dann ist auch der Benchmark selbst eine schlechte Wahl. Euer Entwickler sollte einen Benchmark entwickeln, der die Performance eurer Software ermittelt, oder einer vergleichbaren Operation.Also ist der Server nicht exklusiv für eure Software.
Nein, ist er nicht.
Dann ist der Benchmark unfähig, den Server auszulasten?
Naja, eine VM hat temporär 16vCPU's bekommen.
Führe ich sysbench mit 16 oder 100 Threads aus, gehen alle Kerne der VM auf 100% während der Test ausgeführt wird.
Der Benchmark kann den Server schon zu 100% auslasten.
Zitat von @Ueba3ba:
Die neue Hardware wurde dem Kunden schon verkauft und ist bereits produktiv im Einsatz. Wurde von mir verkauft.
Hast den Developer schon mal gefragt wie er die neue Hardware dem Kunden verkaufen will, wenn der keine Probleme hat?
Die neue Hardware wurde dem Kunden schon verkauft und ist bereits produktiv im Einsatz. Wurde von mir verkauft.
Ich meine was er mit seinem Benchmark bezwecken will. Wenn der Kunde zufrieden ist und du kommst wieder mit neuer Hardware für +5% Leistung und vermutlich mehr als +5% Euro.
Weil du Indizes angesprochen hast. Das hat der Entwickler doch hoffentlich optimiert. Unser SCCM lief eine Zeit lang ohne die Aufräumroutinen... allein die zu aktivieren hat das Ding von extrem langsam zu brauchbar gebracht. (Soweit, dass wir bis heute die Custom Scripts nicht implementiert haben, die noch mehr versprechen...)
Mit Hardware hätten wir da ordentlich einzahlen können...
Moin,
Indizes und vernünftig strukturierte und aufgeräumte Datenbanken (bei uns MySQL) bringen deutlich mehr als x% Leistungsgewinn durch neue Serverhardware. Wir fragen mittlerweile bis zu 40.000 Datenkombinationen (DATUMZEIT + WERT) innerhalb von einer Sekunde ab. Ohne Indizes und optimierter Datenbank waren das vorher locker 15-30 Sekunden. Unser neuer Server, der vor der Optimierung angeschafft wurde, hat uns vielleicht nen Bruchteil (gemessen) gebracht.
Also am besten da mal schauen und optimieren
Indizes und vernünftig strukturierte und aufgeräumte Datenbanken (bei uns MySQL) bringen deutlich mehr als x% Leistungsgewinn durch neue Serverhardware. Wir fragen mittlerweile bis zu 40.000 Datenkombinationen (DATUMZEIT + WERT) innerhalb von einer Sekunde ab. Ohne Indizes und optimierter Datenbank waren das vorher locker 15-30 Sekunden. Unser neuer Server, der vor der Optimierung angeschafft wurde, hat uns vielleicht nen Bruchteil (gemessen) gebracht.
Also am besten da mal schauen und optimieren
Ich meine was er mit seinem Benchmark bezwecken will. Wenn der Kunde zufrieden ist >und du kommst wieder mit neuer Hardware für +5% Leistung und vermutlich mehr als > +5% Euro.
Ich denke damit soll von der schlechten Programmierung abgelenkt werden.
Weil du Indizes angesprochen hast. Das hat der Entwickler doch hoffentlich optimiert. > Unser SCCM lief eine Zeit lang ohne die Aufräumroutinen
Ich glaube nicht. Immer wenn es angesprochen wird, wird davon abgelenkt.
Indizes und vernünftig strukturierte und aufgeräumte Datenbanken (bei uns MySQL) > bringen deutlich mehr als x% Leistungsgewinn durch neue Serverhardware
Das vermuten wir schon lange. Stoßen allerdings auf taube Ohren.
Moin @Ueba3ba,
Ich denke damit soll von der schlechten Programmierung abgelenkt werden.
das muss nicht wirklich sein.
Denn zum einen ist, vorausgesetzt das Notebook hat auch eine anständige Kühlung, was CPU und RAM angeht, durchaus etwas mehr Bums und auch die SSD, wird in diesem nativ mit 4K oder gar 512B adressiert. Das sind alles Dinge, die bei einem SQL Server, auch performanceentscheidend sind.
Des weiteren sind die meisten Server heute per Default nicht wirklich für Performance sondern eher zum Stromsparen konfiguriert und auch die NIC Default Einstellungen, die eigentlich sehr wichtig für eine gute Netzwerkperformance sind, kann man beim Hyper-V leider höchstens den Hasen als Notfutter zum Fressen geben. 😔😭
Noch ein weiterer Punkt. Wenn der Entwickler den SQL Server nativ auf seinem Notebook betreibt dann ist er Netzwerktechnisch eh im Vorteil, zumindest dann, wenn der vSwitch eures Hyper-V's und auch die entsprechenden VM's, nicht mit VMQ oder SR-IOV laufen, wovon ich stand jetzt jedoch zu 99% ausgehe.
Aber, eine korrekte Programmierung ist mitunter dennoch das wichtigste.
Ich glaube nicht. Immer wenn es angesprochen wird, wird davon abgelenkt.
Das vermuten wir schon lange. Stoßen allerdings auf taube Ohren.
Ob der Programmierer bei der Programmierung, zumindest im Hinblick auf die SQL's geschlampt hat, kannst du ganz einfach mit den Bordmitteln des SQL-Servers rausfinden.
Sprich, einfach den Abfragespreicher auf der entsprechenden DB aktivieren, diesen ein bisschen die Daten sammeln lassen und schon kannst du über diverse Auswertungsmöglichkeiten sehen, wo der Entwickler eventuell Murks gebaut hat. 😉
https://learn.microsoft.com/de-de/sql/relational-databases/performance/m ...
By the way, der Abfragespeicher schlägt dir sogar vor welche Indizes du genau setzen kannst und sagt dir auch gleich um wieviel schneller die entsprechende Abfrage dadurch wahrscheinlich laufen würde.
Gruss Alex
Ich meine was er mit seinem Benchmark bezwecken will. Wenn der Kunde zufrieden ist >und du kommst wieder mit neuer Hardware für +5% Leistung und vermutlich mehr als > +5% Euro.
Ich denke damit soll von der schlechten Programmierung abgelenkt werden.
das muss nicht wirklich sein.
Denn zum einen ist, vorausgesetzt das Notebook hat auch eine anständige Kühlung, was CPU und RAM angeht, durchaus etwas mehr Bums und auch die SSD, wird in diesem nativ mit 4K oder gar 512B adressiert. Das sind alles Dinge, die bei einem SQL Server, auch performanceentscheidend sind.
Des weiteren sind die meisten Server heute per Default nicht wirklich für Performance sondern eher zum Stromsparen konfiguriert und auch die NIC Default Einstellungen, die eigentlich sehr wichtig für eine gute Netzwerkperformance sind, kann man beim Hyper-V leider höchstens den Hasen als Notfutter zum Fressen geben. 😔😭
Noch ein weiterer Punkt. Wenn der Entwickler den SQL Server nativ auf seinem Notebook betreibt dann ist er Netzwerktechnisch eh im Vorteil, zumindest dann, wenn der vSwitch eures Hyper-V's und auch die entsprechenden VM's, nicht mit VMQ oder SR-IOV laufen, wovon ich stand jetzt jedoch zu 99% ausgehe.
Aber, eine korrekte Programmierung ist mitunter dennoch das wichtigste.
Weil du Indizes angesprochen hast. Das hat der Entwickler doch hoffentlich optimiert. > Unser SCCM lief eine Zeit lang ohne die Aufräumroutinen
Ich glaube nicht. Immer wenn es angesprochen wird, wird davon abgelenkt.
Indizes und vernünftig strukturierte und aufgeräumte Datenbanken (bei uns MySQL) > bringen deutlich mehr als x% Leistungsgewinn durch neue Serverhardware
Das vermuten wir schon lange. Stoßen allerdings auf taube Ohren.
Ob der Programmierer bei der Programmierung, zumindest im Hinblick auf die SQL's geschlampt hat, kannst du ganz einfach mit den Bordmitteln des SQL-Servers rausfinden.
Sprich, einfach den Abfragespreicher auf der entsprechenden DB aktivieren, diesen ein bisschen die Daten sammeln lassen und schon kannst du über diverse Auswertungsmöglichkeiten sehen, wo der Entwickler eventuell Murks gebaut hat. 😉
https://learn.microsoft.com/de-de/sql/relational-databases/performance/m ...
By the way, der Abfragespeicher schlägt dir sogar vor welche Indizes du genau setzen kannst und sagt dir auch gleich um wieviel schneller die entsprechende Abfrage dadurch wahrscheinlich laufen würde.
Gruss Alex
1
