4

I have an app (windows service) local to the SQL Server box. It calls a stored procedure on the SQL Server box that returns a ton of data and thus causes ASYNC_NETWORK_IO wait.

The database connection from is of Shared Memory type (I double checked for sanity). Why would there be a ASYNC_NETWORK_IO wait type on Shared Memory connection?

I thought ASYNC_NETWORK_IO had to do with a network lag?

5
  • 3
    No, it doesn't only relate to network problems (that's just one reason). Most likely it's actually your app not consuming your data fast enough. See Joe Sacks's article.
    – Marian
    Commented Jan 28, 2014 at 21:31
  • 1
    Is there anything about this scenario that wasn't answered here? Commented Jan 28, 2014 at 21:32
  • Oops, I missed the previous question. SQL Server treats your connections transparent enough so that you'll have the same wait types when using TCP-IP or Share memory. You have answered your own question by stating that "It calls a sproc on the SQL Server box that returns a ton of data and thus causes ASYNC_NETWORK_IO wait". I believe this can be closed as a duplicate, if there's no different question.
    – Marian
    Commented Jan 28, 2014 at 21:43
  • @AaronBertrand It was partially answered in the linked question. I just wanted to make sure that this type of wait can also be applied to a non-network issue. Commented Jan 28, 2014 at 21:47
  • 1
    Shared memory still uses a fixed size buffer (I presume) so it is still possible for the server to need to wait on the client to consume more rows before being able to continue adding to it. Commented Jan 28, 2014 at 22:17

1 Answer 1

2

As far as SQL Server is concerned, whenever results are going out the door, it's ASYNC_NETWORK_IO whether it's shared memory or TCP/IP.

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.