it-swarm.com.de

Riesige Ressourcen vom Typ "Netzwerk-E / A" warten

Wir haben eine in WinDev entwickelte interne Anwendung, die eine Microsoft SQL Server 2012 SP2-Datenbank (Build 11.0.5058) verwendet, die unter Windows Server 2008R2 ausgeführt wird.

Wir haben Leistungsprobleme. Gleichzeitig zeigt Activity Monitor eine große Anzahl von Wartezeiten vom Typ "Netzwerk-E/A" an, wobei "riesig" in diesem Fall eine kumulierte Wartezeit von 7 Millionen Sekunden für einen Server ist, der weniger als 6 Tage in Betrieb ist:

(enter image description here

Die Netzwerkkonnektivität selbst ist in Ordnung, der Server ist mit 10G verbunden, während der Client entweder ein physischer Desktop mit 1 GB oder ein Remotedesktop-Server mit 10 GB ist. Die Netzwerküberwachung zeigt weder eine Verbindungssättigung noch andere Netzwerkprobleme. CPU, RAM und Festplatten-E/A sind ebenfalls in Ordnung.

Nach dem, was ich über Netzwerk-E/A-Wartezeiten gelesen habe, bezieht es sich auf Datensätze, die von einer Abfrage zurückgegeben wurden und nicht von den Clients verwendet werden. Daher denke ich, dass das Problem in der Anwendung liegt, aber es fällt mir schwer, die Entwickler dies untersuchen zu lassen (nicht, dass sie nicht dazu bereit sind, aber sie sind ziemlich beschäftigt und es scheint, dass sie keine Ahnung von der Wurzel haben Ursache und wie man es löst)

Also die Fragen:

  • Habe ich Recht, dass das Leistungsproblem mit den Wartezeiten der Netzwerk-E/A zusammenhängt?

  • welchen Hinweis könnte ich dem Entwicklerteam geben, um die Ursache zu ermitteln?

  • gibt es neben der Korrektur der Anwendung einige Feinabstimmungen, die ich am SQL Server selbst vornehmen kann, um das Problem zu beheben?

6
JFL
  1. Beenden Sie die Verwendung von Aktivitätsmonitor
  2. Verwenden Sie sp_WhoIsActive , um herauszufinden, was tatsächlich los ist

Es könnten Backups sein. In diesem Fall gibt es nicht viel, was Sie tun können , das keine Hardware-Upgrades beinhaltet (vielleicht war 1 Gbit iSCSI keine so gute Idee ...)

Es kann sich um clientseitigen Code handeln, der Daten-RBAR verbraucht (denken Sie an jede Schleife für jede eingehende Zeile) oder um die gleichzeitige Anforderung vieler Zeilen ( Hier kann Paging-Abfragen helfen).

Es könnte etwas ganz anderes sein!

Um eine Vorstellung davon zu bekommen, worauf Ihr Server am meisten wartet, gehen Sie zu firstresponderkit.org - vollständige Offenlegung, ich trage zu diesem Open-Source-Projekt bei - und greifen Sie zu sp_BlitzFirst (oder, zum Teufel, schnapp sie dir alle).

Sie können diesen Befehl ausführen, um Ihre Wartestatistiken seit dem Start als Ganzes anzuzeigen.

EXEC sp_BlitzFirst @SinceStartup = 1

Oder dies, um eine Stichprobe von Wartestatistiken während einer Verlangsamung zu erhalten.

EXEC sp_BlitzFirst @Seconds = 30, @ExpertMode = 1

Hoffe das hilft!

10
Erik Darling

Überwachen Sie die von ihrer Anwendung kommenden Abfragen, einschließlich der Wartezeiten (Sie können dies mit erweiterten Ereignissen tun), und führen Sie dann dieselben Abfragen von sqlcmd oder SSMS aus (jedoch nicht mit Ergebnissen für das Raster) aus und vergleichen Sie sie. Dies soll Ihnen helfen, zwischen Anwendungen zu unterscheiden, die Ergebnisse nicht schnell genug verarbeiten können, und einem Netzwerk, das Daten nicht schnell genug übertragen kann.

Ich weiß nicht, ob "Netzwerk-E/A" in Activity Monitor nur ASYNC_NETWORK_IO zugeordnet ist, aber in einem Netzwerk wie Ihrem wird das Warten mit ziemlicher Sicherheit nur durch Verzögerungen beim Client-Verbrauch verursacht.

6
Aaron Bertrand