Hallo,
SQL2014 Standard läuft virtuell mit 4Cores.
Die Verbindung Host - Clients läuft über eine 10G Netzwerkleitung.
Der Zugriff von den Clients (Anwendung) ist sehr schleppend zeitweise wieder schnell ohne ersichtlichen Grund.
Auf VM-SQL Seite ist weder eine RAM Knappheit (24GB) noch eine erhöhte CPU Belastung - nicht mal zeitweise -> auf deutsch der Server langweilt sich.
Zum Test wurde FW und Virenschutz schon komplett deaktiviert (keine Besserung)
Gemessen wird mit iperf3 (bei schneller bzw. langsamer Verbindung) kein Unterschied - immer gleich schnell
Auf SQL Seite ist als Verbindung TCP gewählt.
Frage:
ist das Aktivieren von tcp + named pipes leistungsteigernd?
oder
muss der SQL Server anderweitig optimiert werden?
oder
sinkt die SQL Leistung (virtuell) ab einer gewissen Userzahl ab.
Gruß Andipc
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
SQL2014 auf VM - sehr langsamer Zugriff der Clients
Moderatoren: Dayworker, continuum, irix
Hallo,
das ist ein wenig Kaffeesatzlesen, daher ein paar Fragen:
- wieviele CPUs bzw. Cores und RAM hat der ESX-Host auf dem die VM läuft
- wieviel der ESX-Host-Ressourcen sind für andere VMs vergeben
- sind die Performancewerte des ESX-Hosts geprüft worden?! (esxtop oder Performancegraphen -> http://www.vfrank.org/esxtop/)
Mal von der Virtualisierung abgesehen, ist der Activity Monitor im SQL Management Studio ist der erste Anlaufpunkt um Probleme bzgl. der Performance zu erkennen. Hier sind gerade sollte man sich "Recent Expensive Queries" anschauen und unter "Processe" sollten langlaufende SQL-Statements bzw. Locks erkennbar sein. Auch sieht man hier den kumulierten IO des SQL-Servers.
Zu deinen Fragen:
- nein
- vermutlich
- nein
das ist ein wenig Kaffeesatzlesen, daher ein paar Fragen:
- wieviele CPUs bzw. Cores und RAM hat der ESX-Host auf dem die VM läuft
- wieviel der ESX-Host-Ressourcen sind für andere VMs vergeben
- sind die Performancewerte des ESX-Hosts geprüft worden?! (esxtop oder Performancegraphen -> http://www.vfrank.org/esxtop/)
Mal von der Virtualisierung abgesehen, ist der Activity Monitor im SQL Management Studio ist der erste Anlaufpunkt um Probleme bzgl. der Performance zu erkennen. Hier sind gerade sollte man sich "Recent Expensive Queries" anschauen und unter "Processe" sollten langlaufende SQL-Statements bzw. Locks erkennbar sein. Auch sieht man hier den kumulierten IO des SQL-Servers.
Zu deinen Fragen:
- nein
- vermutlich
- nein
Hallo,
- wieviele CPUs bzw. Cores und RAM hat der ESX-Host auf dem die VM läuft
2x INTEL XEON E5-2620V3 6C/12T insg. 64GB
6x SAS 6G 600GB 10K HOT PL 2.5 BC (wenn die Frage nach den HD´s fallen würde)
- wieviel der ESX-Host-Ressourcen sind für andere VMs vergeben
insg. 20GB Ram und 12Cores für andere VMs.
- sind die Performancewerte des ESX-Hosts geprüft worden?!
nein, nicht mit dem gelinktem Tool
Für die SQL Konfig ist ein Anwendungstechniker zuständig (habe ich also nicht erstellt)
Habe hier die Werte bekommen und
Async_Network_IO lag bei 39%
Zeitgleich ist die CPU Auslastung auf Host und VM selbst gering. Die Netzauslastung ebenso.
Mit iperf3 wurde in schnellen wie in langsamen Zyklen gemessen - kein Einbruch.
Das seltsame an der Sache ist das es 4 Stunden sehr flüssig läuft und ohne Anzeigen von CPU, Ram und Netzwerkauslastung einbricht bei den Clients.
Gruß Andreas
- wieviele CPUs bzw. Cores und RAM hat der ESX-Host auf dem die VM läuft
2x INTEL XEON E5-2620V3 6C/12T insg. 64GB
6x SAS 6G 600GB 10K HOT PL 2.5 BC (wenn die Frage nach den HD´s fallen würde)
- wieviel der ESX-Host-Ressourcen sind für andere VMs vergeben
insg. 20GB Ram und 12Cores für andere VMs.
- sind die Performancewerte des ESX-Hosts geprüft worden?!
nein, nicht mit dem gelinktem Tool
Für die SQL Konfig ist ein Anwendungstechniker zuständig (habe ich also nicht erstellt)
Habe hier die Werte bekommen und
Async_Network_IO lag bei 39%
Zeitgleich ist die CPU Auslastung auf Host und VM selbst gering. Die Netzauslastung ebenso.
Mit iperf3 wurde in schnellen wie in langsamen Zyklen gemessen - kein Einbruch.
Das seltsame an der Sache ist das es 4 Stunden sehr flüssig läuft und ohne Anzeigen von CPU, Ram und Netzwerkauslastung einbricht bei den Clients.
Gruß Andreas
Hallo,
Async_Network_IO-Waits sind Wartezustände bei denen der SQL-Server auf das Okay vom Client wartet, dass dieser die Daten verarbeitet hat und bereit für die nächsten Daten ist. Das es dazu kommt kann an der Applikation liegen, sprich die Result-Sets vom SQL-Server müssen erstmal in der Applikation verarbeitet werden. Schönes Szenario ist, die Applikation fragt tausende von Datensätzen in einem Query ab, verarbeitet jeden dieser Datensätze sequentiell.
Wie sehr unter Last ist den der Client?! Wenn die Applikation so gestrickt ist, den SQL-Server nur als "dumme" Datenhalte zu benutzen und keine wirkliche Verarbeitung im SQL-Server stattfindet durch Stored Procedures etc., dann müsste die Verarbeitung ja auf dem Client stattfinden und somit CPU-Last erzeugen.
Das Netzwerk könnte auch eine Ursache für diesen Wait-Typ sein, wenn es zu wiederholten TCP Retransmissions kommt, weil die Verbindung immer wieder abbricht dann würde dieser Wait-Typ auch auftauchen. Eigentlich sollten man das auch bei einem
iperf-Test sehen, ob so ein grundsätzlichen Problemen besteht, aber ich würde mir zusätzlich in den ESX-Performance-Charts das Netzwerk anschauen.(Packet Transmit/Receive Errors, Transmit/Receive Packets dropped)
Wie "komplex" ist denn die Applikation?! Könnte man diese auf einer VM starten, die mit auf dem selben ESX-Host läuft? So könnte man das Netzwerk welches zwischen Client und Server liegt als Ursache komplett ausschließen.
Viele Grüße, S.
Async_Network_IO-Waits sind Wartezustände bei denen der SQL-Server auf das Okay vom Client wartet, dass dieser die Daten verarbeitet hat und bereit für die nächsten Daten ist. Das es dazu kommt kann an der Applikation liegen, sprich die Result-Sets vom SQL-Server müssen erstmal in der Applikation verarbeitet werden. Schönes Szenario ist, die Applikation fragt tausende von Datensätzen in einem Query ab, verarbeitet jeden dieser Datensätze sequentiell.
Wie sehr unter Last ist den der Client?! Wenn die Applikation so gestrickt ist, den SQL-Server nur als "dumme" Datenhalte zu benutzen und keine wirkliche Verarbeitung im SQL-Server stattfindet durch Stored Procedures etc., dann müsste die Verarbeitung ja auf dem Client stattfinden und somit CPU-Last erzeugen.
Das Netzwerk könnte auch eine Ursache für diesen Wait-Typ sein, wenn es zu wiederholten TCP Retransmissions kommt, weil die Verbindung immer wieder abbricht dann würde dieser Wait-Typ auch auftauchen. Eigentlich sollten man das auch bei einem
iperf-Test sehen, ob so ein grundsätzlichen Problemen besteht, aber ich würde mir zusätzlich in den ESX-Performance-Charts das Netzwerk anschauen.(Packet Transmit/Receive Errors, Transmit/Receive Packets dropped)
Wie "komplex" ist denn die Applikation?! Könnte man diese auf einer VM starten, die mit auf dem selben ESX-Host läuft? So könnte man das Netzwerk welches zwischen Client und Server liegt als Ursache komplett ausschließen.
Viele Grüße, S.
Hallo,
das mit den Query Abfragen kommt schon hin. In jeder Listenansicht (Client) waren 5000 Sätze eingestellt. Es wurde jedoch auch nicht besser als das auf 500 gedrosselt wurde.
Leider steigt auch die CPU Last am Client nicht an (also weder VM noch Client verzeichnen eine signifikante Last weder RAM, CPU noch Netzwerklast)
Eine VM (auf dem selben Host) mit dieser APP (Selectline wawi) bricht jedoch nicht zusammen (wurde als Testclient aufgebaut).
Somit könnte das Netzwerk Switch noch als Sündenbock herhalten. Hier ist im Log kein einziger Fehler enthalten.
Wie du schon sagst sollte dieser Wait-Typ mit einem iperf Test zu sehen sein (Einbruch), leider negativ. Der iperf Test bringt die gleich hohen Werte ob das Teil nun schnell läuft oder nicht.
Die ESX Performance Charts habe ich nur auf dem vsphere Client immer nur in Richtung Nutzung und Datenübertragungsrate angesehen.
Packet Transmit und Co habe ich mir noch nicht einblenden lassen (werde ich mal)
Gruß Andreas
Auf die
das mit den Query Abfragen kommt schon hin. In jeder Listenansicht (Client) waren 5000 Sätze eingestellt. Es wurde jedoch auch nicht besser als das auf 500 gedrosselt wurde.
Leider steigt auch die CPU Last am Client nicht an (also weder VM noch Client verzeichnen eine signifikante Last weder RAM, CPU noch Netzwerklast)
Eine VM (auf dem selben Host) mit dieser APP (Selectline wawi) bricht jedoch nicht zusammen (wurde als Testclient aufgebaut).
Somit könnte das Netzwerk Switch noch als Sündenbock herhalten. Hier ist im Log kein einziger Fehler enthalten.
Wie du schon sagst sollte dieser Wait-Typ mit einem iperf Test zu sehen sein (Einbruch), leider negativ. Der iperf Test bringt die gleich hohen Werte ob das Teil nun schnell läuft oder nicht.
Die ESX Performance Charts habe ich nur auf dem vsphere Client immer nur in Richtung Nutzung und Datenübertragungsrate angesehen.
Packet Transmit und Co habe ich mir noch nicht einblenden lassen (werde ich mal)
Gruß Andreas
Auf die
[quote="andipc"]
Eine VM (auf dem selben Host) mit dieser APP (Selectline wawi) bricht jedoch nicht zusammen (wurde als Testclient aufgebaut).
Somit könnte das Netzwerk Switch noch als Sündenbock herhalten. Hier ist im Log kein einziger Fehler enthalten.
/quote]
Wie sieht denn das Netz sonst so aus?! Befinden sich der Client und der Server in einem IP-Subnetz?
[quote="andipc"]Hallo,
das mit den Query Abfragen kommt schon hin. In jeder Listenansicht (Client) waren 5000 Sätze eingestellt. Es wurde jedoch auch nicht besser als das auf 500 gedrosselt wurde.
Leider steigt auch die CPU Last am Client nicht an (also weder VM noch Client verzeichnen eine signifikante Last weder RAM, CPU noch Netzwerklast)
/quote]
Dann bitte doch mal die "Recent Expensive Queries" genauer anschauen, mit einem Rechtsklick auein Querie kann man sich da den Ausführungsplan anzeigen lassen, da wird dann ggf. auch angezeigt, ob eventuell ein Index eine Leistungssteigerung bringen würde.
Gruß, S.
Eine VM (auf dem selben Host) mit dieser APP (Selectline wawi) bricht jedoch nicht zusammen (wurde als Testclient aufgebaut).
Somit könnte das Netzwerk Switch noch als Sündenbock herhalten. Hier ist im Log kein einziger Fehler enthalten.
/quote]
Wie sieht denn das Netz sonst so aus?! Befinden sich der Client und der Server in einem IP-Subnetz?
[quote="andipc"]Hallo,
das mit den Query Abfragen kommt schon hin. In jeder Listenansicht (Client) waren 5000 Sätze eingestellt. Es wurde jedoch auch nicht besser als das auf 500 gedrosselt wurde.
Leider steigt auch die CPU Last am Client nicht an (also weder VM noch Client verzeichnen eine signifikante Last weder RAM, CPU noch Netzwerklast)
/quote]
Dann bitte doch mal die "Recent Expensive Queries" genauer anschauen, mit einem Rechtsklick auein Querie kann man sich da den Ausführungsplan anzeigen lassen, da wird dann ggf. auch angezeigt, ob eventuell ein Index eine Leistungssteigerung bringen würde.
Gruß, S.
Hallo,
Clients und Server befinden sich in einem IP-Subnetz
(die Anwendung war vorher auf einem physikalischen Server - also nix neues, nur statt der SQL Runtime jetzt die 4Cores wegen der vm)
Die Clients werden langsamer oder schneller ohne das wir etwas tun (weder Neustart noch sonstwas), alles aus heiterem Himmel.
Wie schon geschrieben findet auch keine Last seitens CPU, Ram, Netzwerk oder auf dem ESX statt.
Das mit den Recent Expensive Queries leite ich gerne mal weiter, da sich im Moment ein Anwendungstechniker um den SQL Server und den Fehler speziell kümmert.
Gruß Andreas
Clients und Server befinden sich in einem IP-Subnetz
(die Anwendung war vorher auf einem physikalischen Server - also nix neues, nur statt der SQL Runtime jetzt die 4Cores wegen der vm)
Die Clients werden langsamer oder schneller ohne das wir etwas tun (weder Neustart noch sonstwas), alles aus heiterem Himmel.
Wie schon geschrieben findet auch keine Last seitens CPU, Ram, Netzwerk oder auf dem ESX statt.
Das mit den Recent Expensive Queries leite ich gerne mal weiter, da sich im Moment ein Anwendungstechniker um den SQL Server und den Fehler speziell kümmert.
Gruß Andreas
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast