Waitopedia is a comprehensive resource of information about SQL Server waits.

The description shown below is the top answer as voted by the Spotlight community.

The charts are based on 2.1 TB of data collected from 4207 instances uploaded by 323 Spotlight users over an 8 week period.


Category: Network
SQL Server versions: 2005, 2008, 2008 R2, 2012, 2014, 2016, 2017


3 Answers


In my environment, this wait is due entirely to two causes: 1) a third-part commercial application written in Microsoft Access (with a SQL Server back-end) and 2) Excel spreadsheets that directly query views and tables. This is mostly harmless, merely creating noise in monitoring tools. However, if anything needs to get a schema lock, an open session stuck in an ASYNC_NETWORK_IO wait will block the session needing the schema lock. That, in turn, will block all other sessions from accessing the same table. This can be catastrophic. There are no cures for this, only workarounds.

One is to enable snapshot isolation, if appropriate in your environment. (Although this won't help with the schema lock issue.) While we cannot us snapshot as a default, we create stored procedures that use snapshot isolation for our Excel users. This has dramatically reduced the frequency of blocking and deadlock issues (the Excel process was almost always the one blocked or chosen as the deadlock victim).

Another is to create a stored procedure that automatically kills sessions stuck in an ASYNC_NETWORK_IO for a very long period of time (perhaps every 15 minutes), or if it is blocking a schema lock, even a very short time (such as every 15 seconds). Of course, you'll also need an Agent Job to run it at the desired frequency.

From http://www.sqlservercentral.com/Forums/Topic1141649-391-1.aspx:

The “async network io” (in SQL 2005/2008) and “networkio” (in SQL 2000) wait types can point to network related issues, but most often are caused by a client application that is not processing results from the SQL Server quickly enough. This will result in filling the network buffers so that SQL Server cannot send more data to the client. Therefore, the process executing the batch will need to wait for the ability to continue sending results to the client.

Reducing Waits / Wait times: If there are significant wait times on “async network io’, review the client applications. Most often, client applications will process rows one at a time using fetches. This may cause the server process to wait on “async network io” when serving up many rows. If this is the issue, there is nothing you can do to improve the SQL Server process performance. Instead, the client application (or middle tier if a web application) may need to be modified to allow for more efficient retrieval of data. Review the following list for client application issues: • Some applications, such as Microsoft Access, will ask for large result sets (typically identified by select statements with no where clause or full table scans), and then further filter the data on the client. If this is causing significant wait time, see if it’s possible to create a view for the client application to use instead. This will significantly reduce the amount of data being pushed to client since all of the filtering will done on SQL Server. Another fix could be to add a ‘where clause’ or further restrict the query so that less data is being sent to the client. • Identify large result sets and verify with the application or developer team how the data is being consumed. If the application is querying large result sets but using only a few rows, consider only querying the rows that are needed or use ‘TOP n’ to reduce the number of rows returned. • If you are encountering high “async network io” wait times when performing data loads on the server, make sure the shared memory protocol is enabled for the SQL Server instance and the session is connected using net_transport = ‘Shared memory’. You can determine the net_transport for the connection by looking at the DMV – sys.dm_exec_connections. If the above tuning tips are reviewed and applied, but the server is still is encountering high “async network io” times, then ensure there aren’t any network related issues: • Review counters such as ‘Batch Requests per second’. Any values over 3000 for a 100MB network card are getting excessive. ‘Current Bandwidth’ on the Network Interface with values over 0.6 are getting excessive. • Check network adapter bandwidth - 1 Gigabit is better than 100 megabits and 100 megabits is better than 10 megabits. • Look at your NIC configuration on the server to make sure there are no issues with the physical card. Also, check if autodetect is picking the fastest speed. • Validate all of the network components between the client application and the SQL Server instance (e.g. switches / routers).

Conclusion When a session waits on the "async network io” event, it may be encountering network issues. More likely, however, it may be an issue with the client application not processing the data quickly enough. If the wait times for “async network io” are high, review the client application to see if large results sets are being sent to the client. If they are, work with the developers to understand if all the data is needed and reduce the size of result set if possible. Ensure that any data filtering is performed in SQL Server instead of the client by utilizing views or more specific where clauses. Use the ‘TOP n’ clause so that only the rows that the client needs are returned to the client. Investigate network issues, if client application tuning tips do not apply.


Occurs on network writes when the task is blocked behind the network. Verify that the client is processing data from the server. Information from Microsoft®


ASYNC_NETWORK_IO waits occur when the network cannot accept the output SQL Server is sending to a client as fast as SQL Server is able to send it. This occurs either because the network is slow, or because the client machine is slow and can't accept data from the network as fast as SQL Server is trying to send it. In any event, the time spent waiting is included in the duration that SQL Server records for execution of the query, and if this wait stat is occurring, SQL Server will appear to be at fault because of slow execution times, when in fact the execution time is including time that SQL Server can do nothing about. If you execution SELECT * FROM sys.sysprocesses and a substantial number of last wait stats are ASYNC_NEWORK_IO or OLEDB, then performance is degraded RIGHT NOW and the duration counter for currently executing queries is including time that SQL Server can do nothing about.

Very common

This wait is very common for most instances

For each of 4207 instances, we ranked ASYNC_NETWORK_IO on how frequent it is compared to all other recent waits. The chart shows the total of all rankings.

Prevalence of ASYNC_NETWORK_IO across the Spotlight Population

For 68 % of hours with this wait, average wait time is less than 0.51 ms

For each instance, we found all the recent hours when it had a ASYNC_NETWORK_IO wait. We found the average latency for each of those hours.

4190 instances contributed data to this chart

Latency Distribution of ASYNC_NETWORK_IO across the Spotlight Population