Warum treten async_network_io-Wartetypen auf?

Letzte Woche ist etwas Seltsames in unserer Datenbank passiert. Plötzlich wurde die Anwendung für unsere Benutzer blockiert, die keine neuen Entitäten usw. speichern konnten. Nachdem ich mir den Aktivitätsmonitor des SQL Servers (2008 mit Kompatibilitätsmodus 2005) angesehen hatte, sah ich die folgenden drei Einträge:

Nach einiger Zeit erhielten die Benutzer ein Verbindungszeitlimit. Wenn ich den Prozess 64 beendet habe, konnten sie wieder normal speichern.

Das Problem ist, dass die Entitäten, die sie während des Blocks speichern wollten, mehr als einmal (bis zu dreimal) in die Datenbank eingefügt wurden, obwohl es Code gibt, der dies verhindern sollte (Zahlenspalte, die eindeutig, aber ohne Einschränkung sein muss ... die Prüfung erfolgt im Code).

Wir verwenden Entity Framework 6.0.

• Weiß jemand von euch, warum und wann diese ASYNC_NETWORK_IO-Wartetypen auftreten und wie man sie vermeidet?
• Und was genau meinen sie?

ASYNC_NETWORK_IOzeigt irgendwie an, dass die Clientanwendung die Ergebnisse nicht so schnell verarbeitet, wie SQL Server sie füttert. Dies kann durch ein Problem mit der Clientanwendung oder mit der Netzwerkverbindung zwischen dem Server und der Clientanwendung verursacht werden.

Bitte beziehen Sie sich auf einen Beitrag von Thomas LaRock

Die Wartezeit ASYNC_NETWORK_IO zeigt an, dass eines von zwei Szenarien auftritt. Das erste Szenario besteht darin, dass die Sitzung (dh SPID) darauf wartet, dass die Clientanwendung die Ergebnismenge verarbeitet und ein Signal an SQL Server zurücksendet, dass sie bereit ist, weitere Daten zu verarbeiten. Das zweite ist, dass möglicherweise ein Problem mit der Netzwerkleistung vorliegt.

oder dieser Beitrag von Joe Sack

Wie Sie vielleicht bereits wissen, sind die Wartetypen ASYNC_NETWORK_IO (in SQL 2005) und NETWORKIO (in SQL 2000 angezeigt) entweder einer aufrufenden Anwendung zugeordnet, die Ergebnisse von SQL Server nicht schnell genug verarbeitet, oder einem Netzwerkleistungsproblem .

Da Sie entity framework diesen Beitrag von Brent Ozar verwenden, kann er auch nützlich sein

Als ich mir die Wartestatistiken für diese Abfragen ansah, sah ich, dass es viele ASYNC_NETWORK_IO gab - oft mehr als 1000 Millisekunden. Das ergab auch keinen Sinn! Wie kann eine Abfrage mit so wenig CPU-Zeit und so wenigen Lesevorgängen so lange dauern? Es ist nicht so, dass die Anwendung nach Millionen von Zeilen gefragt hat und die Ergebnisse nicht schnell genug verbrauchen konnte.

Es gibt einige Missverständnisse bezüglich des Wartetyps ASYNC_NETWORK_IO, hauptsächlich aufgrund des Namens, der auf das Netzwerkproblem hinweist, aber der Grund für diesen Wartetyp ist ziemlich selten.

Übermäßige Wartezeiten bei ASYNC_NETWORK_IO können in zwei Szenarien auftreten:

1. Die Sitzung muss warten, bis die Clientanwendung die von SQL Server empfangenen Daten verarbeitet hat, um das Signal an SQL Server zu senden, dass neue Daten zur Verarbeitung akzeptiert werden können. Dies ist ein häufiges Szenario, das möglicherweise ein schlechtes Anwendungsdesign widerspiegelt und die häufigste Ursache für übermäßige Wartetypwerte für ASYNC_NETWORK_IO ist.

   Dies beinhaltet die Untersuchung der Anwendung, die die übermäßigen Wartetypwerte für ASYNC_NETWORK_IO verursacht, und die häufige Abstimmung mit den Anwendungsentwicklern, die sie erstellt haben.

2. Die Netzwerkbandbreite ist maximal. Ein verstopftes Ethernet führt zu einer langsamen Datenübertragung von der Anwendung hin und her. Dies an und für sich wird die Effizienz der Anwendung beeinträchtigen.

Weitere Details finden Sie auf dieser Seite