14
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: 04.11.2024 um 22:11 Uhr
14 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
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.
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.
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
