Verteilung von logischen Prozessoren auf VMs unter Hyper-V?

Hallo Forum,
ich habe auf einem Hyper-V-Server (2 Prozessoren 2.2 GHz, 12 Kerne, 24 logische Prozessoren) mit zwei virtuellen Servern (Domänencontroller und SQL-Anwendungs-Server) ein Leistungsproblem beim virtuellen Server für SQL und Anwendungen. Ich habe daher versucht, die Performance dieser virtuellen Maschine durch zusätzlichen RAM und durch eine Umkonfiguration der zugewiesenen logischen Prozessorren zu verbessern. Leider verfüge ich in diesem Bereich über keine Erfahrung und die Infos, die ich inzwischen studiert habe, geben für mich derzeit auch kein wirklich aussagekräftiges Ergebnis. Zum Einen sollen zur Leistungssteigerung zusätzliche LPs zugewiesen werden, aber bitte auch nicht zu viele, weil dann die Maschine nicht schneller sondern durchaus sogar langsamer werden kann etc.
Ich habe mich jetzt zu folgender Konfiguration entschlossen: VM Domänencontroller 2 LPs und relative Gewichtung 100 und VM SQL 8 LPs und relative Gewichtung 200. Eigentlich stehen insgesamt ja 24 LPs zur Verfügung. Ist der von mir gewählte Ansatz gut oder sollten der VM SQL weitere LPs zugewiesen werden?
Eure Meinung würde mich interessieren. Dank im Voraus.
Viele Grüße Peter

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 397341

Url: https://administrator.de/contentid/397341

Ausgedruckt am: 26.11.2024 um 07:11 Uhr

12 Kommentare

Neuester Kommentar

Hallo,

Zitat von @Peter02:
Ich habe mich jetzt zu folgender Konfiguration entschlossen: VM Domänencontroller 2 LPs und relative Gewichtung 100 und VM SQL 8 LPs und relative Gewichtung 200. Eigentlich stehen insgesamt ja 24 LPs zur Verfügung. Ist der von mir gewählte Ansatz gut oder sollten der VM SQL weitere LPs zugewiesen werden?

Intel CPUs?
AMD CPUs?
RAM insgesamt und wie pro VM zugeteilt?
SSDs oder HDDs mit SAS oder SATA und 15k oder 10k U/min oder SATAs mit 5400 U/min?
RAID Verbund oder einfach nur Platten am internen Chip oder RAID Verbund am echten RAIB Controller?
Mainboard ist was, Server oder Desktop?
Dein Hyper-V ist 2008, 208R2, 2012, 2012R2, 2016, 2019?
Deine VMs sind Genaeration 1 oder 2?

Gruß,
Peter

von wie vielen Usern reden wir hier denn? Das alles hört sich jetzt nicht nach einem sonderlich grossen Setup an, wehsalb ich hier mal anzweifle, das es sich überhaupt um CPU-Performanceprobleme handelt.
Bei SQL Performance ist äusserst selten die CPU das Problem. in 80%+ ist das DB-Design(besonders die Indexe) beschissen bzw die Queries dazu.
Und beim Rest ist einfach zu wenig IO vorhanden, weil mal wieder an den Festplatten gespart wurde...

Intel CPUs?

Ich tippe mal auf einen Intel Xeon E5-2430v0 oder einen E5-2420v2?
Wie dem auch sei, 2,2 GHz ist jetzt nicht unbedingt der Leistungskracher. Wenn die DB-Operationen eher Single-Core-Leistung benötigen, ist der Flaschenhals klar. Dann kann der VM noch so viele Kerne an den Kopf werfen ;)

Zitat von @anteNope:
Wie dem auch sei, 2,2 GHz ist jetzt nicht unbedingt der Leistungskracher. Wenn die DB-Operationen eher Single-Core-Leistung benötigen, ist der Flaschenhals klar.

Zu dem Thema mal eben.
Einfach mal am Markt umschauen, was gibt es denn heute noch an effektivem Takt?
So 2,5 bis 3 GHz pro Kern, natürlich zzgl. Turbo, aber dieser wird im VM-Umfeld innerhalb der VM gar nicht angegeben (zumindest VMware 6.7),
die Basis verwaltet den zusätzlichen Takt, aber tut sie es wirklich und wann tut sie es?

Einfach mal am Markt umschauen, was gibt es denn heute noch an effektivem Takt?

Der Takt ist stark abhängig von der Kernzahl. Die aktuelle E5-Serie mit um die 20 Kerne hat natürlich auch "nur" 2,2 - 2,4 GHz Basistakt. Bei 6 Kernen kommt ein E-2186G aber schon auf beachtliche 3,8 GHz in Basis und 4,7 GHz im Turbo!

aber dieser wird im VM-Umfeld innerhalb der VM gar nicht angegeben (zumindest VMware 6.7), die Basis verwaltet den zusätzlichen Takt, aber tut sie es wirklich und wann tut sie es?

Bei HyperV funktioniert das im Rahmen der Möglichkeiten der CPU und der Takt wird ab Server 2016 sogar korrekt angezeigt, zumindest im Host-System. Die VM muss das ja zwangsläufig nicht wissen, da reicht die Info zum Basistakt, bei Hyper-V der maximale Basistakt ohne Turbo.

Edit: Mein Tipp, guck dir die Auslastung im Taskmanager auf dem Host an =) Setz den SQL unter Last und guck was passiert.

Wenn ein Kern ausgelastet wird, brauchst du mehr Takt
Wenn mehrere Kerne ausgelastet werden, kannst du ggf. mit mehr Kernen etwas erreichen
Ist kaum Auslastung zu sehen, ist die Ursache woanders zu suchen, ggf. wie schon erwähnt in einer nicht optimalen Datenbankstruktur

Zitat von @anteNope:
Der Takt ist stark abhängig von der Kernzahl

Das ist schon klar, aber wer bitte nutzt einen VM-Server mit nem 6-Kern Prozessor? ;)
Dann will man aktuell AMD unterstützten und so erhält man folgende Auswahl:
https://www.amd.com/de/products/epyc-7000-series-2-socket-models
--> Basistakt max. 2,5 Ghz

Dem SQL einfach mal mehr Kerne zuweisen ist ja auch immer eine Frage der Lizenz.
Wir haben das Thema SQL momentan sehr intensiv durch unser neues ERP System.

Zuvor auf alten Opteron 6174 mit fixen 2,2 GHz und entsprechend träger Antwortzeit,
wurde auf einen Epyc 7261 mit bis zu 2,9 GHz aktualisiert - mit der Aussicht auf Fleischbällchen, wenn AMD zur CES war feines vorstellt.
Da kein nennenswerter Geschwindigkeitsvorteil entstand mal testweise noch auf einem Threadripper mit bis 4 GHz getestet.
Die Kalkulationszeit am SQL wird sich entsprechend reduziert haben, das was davon am Client ankommt ist nicht relevant.

Vorgaben seitens der Software gibt es nicht, einzige Bedingung: 8 Threads am SQL (genutzt werden seitens der Software max. 2, zumindest Prozentual 25 - 30% Last).

So kann ich die Verwirrung um Prozessorenzuweisungen absolut nachvollziehen.

Hallo, erst einmal vielen Dank für eure Rückmeldungen. Beim Server handelt es sich um eine Fujitsu PRIMERGY TX2540 M1 mit 2x Intel(R) Xeon(R) CPU E5-2420 v2 @ 2.20GHz . RAM inzwischen gesamt 48 GB, davon 38 GB dem Anwendungsserver zugewiesen. HDD sind SATA an einem LSI RAID SAS 6G. Hyper-V ist 2012R2. VMs Generation 2. 10 User. Auf der VM läuft nicht nur ein SQL-Server (Mitgliederverwaltung) sondern jetzt auch eine DATEV-Installation, die bisher lokal auf einem Rechner als Standalone betrieben wurde.
Durch die von mir oben beschriebenen Maßnahmen scheint sich die Performance für die Anwender doch deutlich verbessert zu haben. Ich werde jetzt den Anwendern in den nächsten Tagen die Entscheidung überlassen, ob ein neuer Server benötigt wird, Kerne und LPs hin ober her. Klar ist, das schnellere Disks und höhere Prozessorleistung wünschenswert sind, aber es muss alles auch bezahlt werden. Ich bin zwar jetzt etwas schlauer als am Anfang, aber ich habe nach wie vor das Gefühl, dass hier try and error angesagt sind. An Datenbankdesigns und übermäßigen Leistungshunger von Anwendungen kann ich wenig ändern. Also erst einmal vielen Dank für eure Unterstützung.

Hallo Peter,

vielleicht verstehe ich dich falsch, aber zwei VMs mit 8/2 vCPUs ergeben 10 vCPUs und damit eine Unterbelegung der 24 logischen Kerne um fast 60%, die unter keinem Gesichtspunkt sinnvoll ist (es sei denn, man möchte ein System mit bestimmten Charakteristika simulieren). Was machen die anderen 14 logischen Kerne?

Grüße
Richard

Also bei 10 Usern kann man fast blind sagen, das die CPU damit keine Probleme hat.
Bei SATA allerdings ....
Was für Platten und wie viele davon sind das denn?

Leistet euch doch einfach mal 2 Consumer-SSDs und hängt die da rein. Da die SQL Daten drauf (TempDB, DB und Logs) und dann seht ihr ja ob es was bringt. Je nach grösse der DB macht ihr da auch nur 200€ kaputt.

Ansonsten wäre natürlich der analytische Ansatz nicht verkehrt: im SSMS (ich gehe hier mal von MSSQL aus) mal den Activity Monitor befragen. Da kann man meistens schon erkennen, wo der Flaschenhals ist. Ansonsten mit perfmon gucken wo die Wartezeiten sind.

vielleicht verstehe ich dich falsch

Logische Kerne sind bei VMs leider uninteressant. Es zählen nur die phyischen Kerne.

Leistet euch doch einfach mal 2 Consumer-SSDs und hängt die da rein. Da die SQL Daten drauf (TempDB, DB und Logs) und dann seht ihr ja ob es was bringt. Je nach grösse der DB macht ihr da auch nur 200€ kaputt.

Oder gleich die ganze VM da drauf. 500 GB sind ja gerade zum Schnapperpreis zu haben =)