13

Last week something strange happened on our database. All of a sudden, the application blocked for our users who were not able to save new entities etc. After looking at the Activity Monitor of the SQL Server (2008 with compatibility mode 2005) I saw the following three entries:

async_network_io wait types

After some time, the users got a connection timeout. When I killed the process 64, they could save normally again.

The problem is that the entities they tried to save during the block were inserted into the DB more than once (up to 3 times) even though there is code which should prevent this from happening (number column which has to be unique but without a constraint... the check happens in the code).

We use Entity Framework 6.0.

  • Does anyone of you know why and when these ASYNC_NETWORK_IO wait types occur and how to avoid them?
  • And what exactly do they mean?
Improve this question
3
  • 1
    Take a peek at this article from Doug Lane: brentozar.com/archive/2015/07/… This may address what you are seeing with EF.
    – Kris Gruttemeyer
    Commented Jul 21, 2015 at 19:20
  • Very interesting article! Thank you, I'll have a look at it :)
    – xeraphim
    Commented Jul 22, 2015 at 8:49
  • 1
    Check the wait stats repository - ASYNC_NETWORK_IO. Use the script that Paul provides to see if there are other problems.
    – Kin Shah
    Commented Aug 6, 2015 at 13:20

2 Answers 2

Reset to default
16

ASYNC_NETWORK_IO somehow indicates that the client application isn't processing results as fast as SQL Server feeds them. This could be caused by an issue with the client application or with the network connection between the server and the client application.

Please refer to a post by Thomas LaRock

The ASYNC_NETWORK_IO wait indicates that one of two scenarios are happening. The first scenario is that the session (i.e., SPID) is waiting for the client application to process the result set and send a signal back to SQL Server that it is ready to process more data. The second is that there may be a network performance issue.

or this post by Joe Sack

As you may already be aware, the ASYNC_NETWORK_IO (seen in SQL 2005) and NETWORKIO (seen in SQL 2000) wait types are associated with either a calling application that is not processing results quickly enough from SQL Server or is associated with a network performance issue.

Since you are using entity framework this post by Brent Ozar may be useful too

Looking at the wait stats for these queries, I saw there was a lot of ASYNC_NETWORK_IO — often 1000+ milliseconds. That didn’t make any sense either! How can a query with so little CPU time and so few reads take so long to complete? It’s not like the application was asking for millions of rows and couldn’t consume the results fast enough.

Improve this answer
7

There are some misconceptions regarding the ASYNC_NETWORK_IO wait type, primarily because of the name that indicates the network issue, but it is quite rare the reason for this wait type.

Excessive ASYNC_NETWORK_IO waits could occur under two scenarios:

  1. The session must wait for the client application to process the data received from SQL Server in order to send the signal to SQL Server that it can accept new data for processing. This is a common scenario that may reflect bad application design, and is the most often cause of excessive ASYNC_NETWORK_IO wait type values.

    This involves investigating the application that is causing the excessive ASYNC_NETWORK_IO wait type values and often coordinating with the application developers who created it.

  2. Network bandwidth is maxed out. A clogged Ethernet will cause the slow data transmission back and forth from the application. This, in and of itself, will degrade the efficiency of the application.

Much more details can be found on this page

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.