Sie haben diesen Wartetyp schon einmal gesehen, nicht wahr? Nun, es ist sicherlich ein Wartetyp, der für viel Verwirrung gesorgt hat. Der unmittelbare Fokus liegt im Allgemeinen auf dem Wort „NETZWERK“, aber meistens hat es nichts mit dem Netzwerk zu tun!
Der Wartetyp ASYNC_NETWORK_IO führt normalerweise zu zwei Arten von Symptomen. Das erste ist, dass die Arbeitslast der Sitzung darauf wartet, dass die entsprechende Clientanwendung einen bestimmten Datensatz bestätigt/verarbeitet und SQL Server mitteilt, dass sie bereit ist, weitere Daten zu verarbeiten/zu bestätigen. Das zweite Symptom ist, dass möglicherweise ein Leistungsproblem im Netzwerk zwischen der Anwendung und der Datenbankinstanz vorliegt. Im Hintergrund hält SQL Server die Daten in einem Ausgabepuffer, bis vom Client eine Bestätigung empfangen wird, die feststellt, ob der Datenverbrauch vorhanden ist Komplett. ASYNC_NETWORK_IO ist ein verräterisches Zeichen dafür, dass es der Anwendung an Effizienz beim Lesen von Daten fehlt, die sie aus ihrer Backend-Datenbank benötigt. Das zugrunde liegende Netzwerk kann auch Probleme haben, die zu längeren Wartezeiten führen können, während Daten verarbeitet werden und Signale vom Client an den Server zurückgesendet werden.
Mögliche Ursachen für diese Wartezeit sind:
- Anwendungscode ruft Daten nicht korrekt ab
- Große Datensätze, die vom Client angefordert werden
- Übermäßiges Filtern von Daten auf Client- oder Anwendungsseite
- Schlecht konfigurierte Netzwerkgeräte wie Karten, Switches usw.
Auf hoher Ebene möchte ein DBA möglicherweise Folgendes überprüfen:
- Überprüfen Sie den Anwendungscode und stellen Sie sicher, dass die Anwendung Daten korrekt/effizient liest. Zieht Ihre Anwendung beispielsweise eine große Anzahl von Zeilen zurück, um jeweils nur eine Zeile zu verarbeiten?
- Unnötige Datenfilterung auf Client-/Anwendungsseite? Begrenzen Sie die Zeilen.
Wenn die oben genannten Elemente auschecken, aber die Probleme mit ASYNC_NETWORK_IO bestehen bleiben, kann dies am Netzwerk liegen. Hier sind einige Dinge, die Sie untersuchen können:
- Untersuchen Sie die Netzwerkkommunikationsverbindung zwischen der Anwendung und der Back-End-Datenbankinstanz und überprüfen Sie die Bandbreite.
- Verwenden Sie sys.dm_io_virtual_file_stats, um das Netzwerk auf allgemeine Latenz aufgrund von Last oder Entfernung zu testen
- Untersuchen Sie die NIC-Konfiguration auf dem Datenbankserver, um sicherzustellen, dass keine Fehler und/oder Einstellungen fehlen.
Der ASYNC_NETWORK_IO WAIT TYPE könnte tatsächlich ein netzwerkbezogenes Problem sein, aber oft kann es an einer Client-Anwendung liegen, die ihre Daten nicht effizient verarbeitet. Wenn letzteres tatsächlich der Fall ist, dann ist dies eine Gelegenheit für DBAS und Entwickler, zusammenzuarbeiten, um zu verstehen, was die Anwendung im besten Interesse der Leistung der Back-End-Datenbank wirklich benötigt. Sicherzustellen, dass die meisten Datenfilter innerhalb von SQL Server durchgeführt werden, ist eine bewährte Methode, die durch Ansichten oder spezifischere Where-Bedingungen in der Transaktionssyntax erreicht werden kann.
Obwohl es viele Möglichkeiten gibt, die ASYNC_NETWORK_IO-Wartezeit durch die Verwendung von katalogisierten DMVs und erweiterten Ereignissen in SQL Server zu überwachen und zu messen, empfehlen wir unserer Community von SQL Server-DBAs, sich die Spotlight Cloud von Quest anzusehen, die eine effiziente Bestimmung der Grundursache des Wartetyps bietet Verbrauch über einen historischen Zeitraum.
