11
Hyper-V + SQL Server langsam
Hallo zusammen,
ich versuche gerade ein Problem für einen unserer Kunden zu lösen.
Ich habe festgestellt das ein SQL Server auf Hyper-V installiert sehr langsam ist gegenüber einer Bare Metal Installation ist.
Ich habe folgenden Testaufbau Server und Hyper-V Client sind beide Server 2012 / R2 . Der SQL Server ist 2014/SP1 Enterprise.
Beim Schreiben von Datensätzen mit unserer Application oder mit meinem selbst zusammengestoppelten Benchmark ist der Hyper-V Client um 2/3 langsamer.
Beide Server sind selbe die Hardware, am Hyper-V läuft nur der "TestSQL" unter Hyper-V.
Das man bei einer Virtualisierung Einbußen hat ist logisch, aber ich denke diese Menge ist etwas zuviel.
Ich habe schon verschiedenste Netzwerkkarten und deren Optimierungen versucht, kein nennenswerter Erfolg.
Viele Einstellungen und Tipps rund um NUMA und SR-IOV habe ich auch schon probiert.
Ich habe von einem Kollegen gehört das es beim SQL Optimierungen von Warteschlangen benötigt, aber dieser konnte mir auch keine Lösung sagen.
Habt Ihr noch Tipps wo ich die Fehlersuche ansetzen kann, am SQL-Server und dessen Einstellungen, am Hyper-V Server, ...
Danke für Eure Tipps.
Mike
ich versuche gerade ein Problem für einen unserer Kunden zu lösen.
Ich habe festgestellt das ein SQL Server auf Hyper-V installiert sehr langsam ist gegenüber einer Bare Metal Installation ist.
Ich habe folgenden Testaufbau Server und Hyper-V Client sind beide Server 2012 / R2 . Der SQL Server ist 2014/SP1 Enterprise.
Beim Schreiben von Datensätzen mit unserer Application oder mit meinem selbst zusammengestoppelten Benchmark ist der Hyper-V Client um 2/3 langsamer.
Beide Server sind selbe die Hardware, am Hyper-V läuft nur der "TestSQL" unter Hyper-V.
Das man bei einer Virtualisierung Einbußen hat ist logisch, aber ich denke diese Menge ist etwas zuviel.
Ich habe schon verschiedenste Netzwerkkarten und deren Optimierungen versucht, kein nennenswerter Erfolg.
Viele Einstellungen und Tipps rund um NUMA und SR-IOV habe ich auch schon probiert.
Ich habe von einem Kollegen gehört das es beim SQL Optimierungen von Warteschlangen benötigt, aber dieser konnte mir auch keine Lösung sagen.
Habt Ihr noch Tipps wo ich die Fehlersuche ansetzen kann, am SQL-Server und dessen Einstellungen, am Hyper-V Server, ...
Danke für Eure Tipps.
Mike
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 296529
Url: https://administrator.de/contentid/296529
Printed on: April 23, 2024 at 21:04 o'clock
11 Comments
Latest comment
Moin,
der SQL ist in einer VM auf Hyper-V installiert? Oder direkt in der Parent Partition?
VG,
Thomas
der SQL ist in einer VM auf Hyper-V installiert? Oder direkt in der Parent Partition?
VG,
Thomas
In der VM.
Siehe Hyper-V und Datenbanken - schlechte Performance
Kann ich exakt so bestätigen. Ich habe mal bei einem Online-Seminar Microsoft's MVP Nils Kaczenski dazu befragt - Antwort: "Ist uns nicht bekannt". Si, claro...
Aber mit Win10 wird es besser und somit evtl. mit Hyper-V-Server 2016.
Kann ich exakt so bestätigen. Ich habe mal bei einem Online-Seminar Microsoft's MVP Nils Kaczenski dazu befragt - Antwort: "Ist uns nicht bekannt". Si, claro...
Aber mit Win10 wird es besser und somit evtl. mit Hyper-V-Server 2016.
Zitat von @DerWoWusste:
Siehe Hyper-V und Datenbanken - schlechte Performance
Kann ich exakt so bestätigen. Ich habe mal bei einem Online-Seminar Microsoft's MVP Nils Kaczensky dazu befragt - Antwort: "Ist uns nicht bekannt". Si, claro...
Aber mit Win10 wird es besser und somit evtl. mit Hyper-V-Server 2016.
Siehe Hyper-V und Datenbanken - schlechte Performance
Kann ich exakt so bestätigen. Ich habe mal bei einem Online-Seminar Microsoft's MVP Nils Kaczensky dazu befragt - Antwort: "Ist uns nicht bekannt". Si, claro...
Aber mit Win10 wird es besser und somit evtl. mit Hyper-V-Server 2016.
Interessant, mich würde dann interessieren wie es Microsoft bei Azure macht.
Mit Kanonen auf Spatzen schiessen.
Ich habe festgestellt das ein SQL Server auf Hyper-V installiert sehr langsam ist gegenüber einer Bare Metal Installation ist.
Hast du bei den beiden Installationen auf SAS Platten gesetzt? Was ich bei einem Kunden mit SQL und HyperV hatte waren in den Einstellungen der VM (bzw. setze ich das generell bei VMs so):-Fest Größe bei VHDX Dateien verwenden
-kein dynamischer RAM
-ausrechende Anzahl an vCPUs - hier gibt es eine Berechnung, glaube das war Anazahl an LPs mal vier ist die gesamte Anzahl an vCPUs die alle Maschinen incl. Host nutzen können.
Danke, dieses habe ich schon beachtet.
Die vCPU Anzahl ist genau so hoch wie die reale CPU Anzahl.
Die vCPU Anzahl ist genau so hoch wie die reale CPU Anzahl.
Hallo,
bei VMware besteht das Problem auch, hier sind Vergleichswerte:
http://vmware-forum.de/viewtopic.php?t=21366
bei VMware besteht das Problem auch, hier sind Vergleichswerte:
http://vmware-forum.de/viewtopic.php?t=21366
Guten Tag zusammen,
habe ein ähnliches Symptom wie von Schicksal beschrieben.
Neuen Hyper-V Host auf Server 2016 Basis installiert.
Kurze Eckdaten des Hosts:
2x CPU Silver 4110
96 GB RAM
AVAGO MegaRAID SAS 9361-8i
1x RAID 1 SSD (Host BS, VM DC)
1x RAID 5 SSD (VM Fileserver, VM SQL Server 2017 Enterprise)
2x NIC Intel X722
Alle VM's GEN 2
Habe der SQL VM 100 CPU Leistung gegeben.
RAM Dynamisch und Fest zugewiesen (32GB) - keine Änderung
VM mit GEN1 versucht gleiches Ergebnis:
Wir haben einen Benchmark durchgeführt - egal auf welchem RAID die VM's laufen, die Ergebnisse sind extrem schlecht.
Wenn wir auf Blech von 2200 Zugriffen/s sprechen sind wir bei der VM bei 240/s.
Kopieren im Netzwerk und zwischen den VM's läuft top.
Hat jemand eine Idee für mich?
Ich weiß der Thread ist schon alt aber er passt genau auf mein Fehlerbild.
habe ein ähnliches Symptom wie von Schicksal beschrieben.
Neuen Hyper-V Host auf Server 2016 Basis installiert.
Kurze Eckdaten des Hosts:
2x CPU Silver 4110
96 GB RAM
AVAGO MegaRAID SAS 9361-8i
1x RAID 1 SSD (Host BS, VM DC)
1x RAID 5 SSD (VM Fileserver, VM SQL Server 2017 Enterprise)
2x NIC Intel X722
Alle VM's GEN 2
Habe der SQL VM 100 CPU Leistung gegeben.
RAM Dynamisch und Fest zugewiesen (32GB) - keine Änderung
VM mit GEN1 versucht gleiches Ergebnis:
Wir haben einen Benchmark durchgeführt - egal auf welchem RAID die VM's laufen, die Ergebnisse sind extrem schlecht.
Wenn wir auf Blech von 2200 Zugriffen/s sprechen sind wir bei der VM bei 240/s.
Kopieren im Netzwerk und zwischen den VM's läuft top.
Hat jemand eine Idee für mich?
Ich weiß der Thread ist schon alt aber er passt genau auf mein Fehlerbild.
Moin.
Ich rate dir, einen neuen Thread zu erstellen.
Hier kann ich nur anfügen, dass das Verhältnis, welches Du schilderst: virtuell 240 Zugriffe pro Sekunde gegenüber 2200 Zugriffen auf Blech, hier nicht beobachtet werden kann unter Server 2016 Hyper-V. Da hatten wir eher einen Faktor von 2x (schneller auf dem Blech), während Du ja einen Faktor von >9 aufweist. Da muss etwas anderes hinterstecken - benutzt Du Snapshots oder Replikation? Die gehen richtig stark in die IO-Leistung.
Ich rate dir, einen neuen Thread zu erstellen.
Hier kann ich nur anfügen, dass das Verhältnis, welches Du schilderst: virtuell 240 Zugriffe pro Sekunde gegenüber 2200 Zugriffen auf Blech, hier nicht beobachtet werden kann unter Server 2016 Hyper-V. Da hatten wir eher einen Faktor von 2x (schneller auf dem Blech), während Du ja einen Faktor von >9 aufweist. Da muss etwas anderes hinterstecken - benutzt Du Snapshots oder Replikation? Die gehen richtig stark in die IO-Leistung.
Tag,
Vielen Dank für deine schnelle Antwort.
Prüfpunkte habe ich jetzt mal deaktiviert.
Replika's laufen keine.
Alles Zwei Stunden macht VEEAM vom Host aus ein Backup der VM's
Werde auf deinen RAT hin aber einen neuen Thread erstellen.
Vielen lieben Dank.
Vielen Dank für deine schnelle Antwort.
Prüfpunkte habe ich jetzt mal deaktiviert.
Replika's laufen keine.
Alles Zwei Stunden macht VEEAM vom Host aus ein Backup der VM's
Werde auf deinen RAT hin aber einen neuen Thread erstellen.
Vielen lieben Dank.
Prüfpunkte, wenn schon erstellt, müssten gelöscht werden. Das ist Gift für die Performance und sollte nicht produktiv eingesetzt werden, jedenfalls nicht dauerhaft, wenn es um Leistung geht.
