¿Es ASYNC_NETWORK_IO tipo de espera algo de qué preocuparse?

Al mirar la lista de procedimientos almacenados que demoran mucho tiempo en ejecutarse, uno se destaca como el que más espera. Sin embargo, la mayor parte de esa espera (81%) es ASYNC_NETWORK_IO y sé por qué: el procedimiento almacenado transfiere aproximadamente 400 MB de información.

En la documentación, indica que la causa de ASYNC_NETWORK_IO es que el cliente no puede mantenerse al día con la avalancha de datos y eso probablemente sea cierto. No estoy seguro de cómo hacer que el cliente se mantenga al día, ya que todo lo que hace es llamar al procedimiento almacenado a través de un ADO.NET y luego solo procesa el conjunto de datos.

Entonces, dada esta información, ¿debería preocuparme por el tipo de espera ASYNC_NETWORK_IO para este procedimiento? ¿Realmente tiene un efecto en el rendimiento del servidor?

Información adicional:

Estoy en el service pack 2 de SQL Server 2005.
La aplicación cliente está en el mismo cuadro que SQL Server (lo sé, lo sé ... pero no puedo hacer nada al respecto).

— AngryHacker
fuente

La mejor manera de pensar en este tipo de espera es que no hay nada en su consulta que lo cause, es devolver datos al cliente. También verá que muchos de ustedes tienen tablas vinculadas en Access. Una posibilidad, dependiendo de la aplicación de su cliente, es dividir los datos en fragmentos más pequeños o simplemente devolver menos datos. Si esa no es una opción, probablemente estará limitado en lo que puede hacer para reducirla.

— JNK

¿Se está conectando la aplicación cliente con la Memoria compartida o TCP / IP? ¿La aplicación cliente y SQL Server comparten el mismo conjunto de núcleos de procesador, o está utilizando una técnica de enmascaramiento de afinidad para separarlos?

— Jon Seigel

Es el tipo de conexión predeterminado, nada especial, por lo que utiliza la memoria compartida. Ambas aplicaciones usan el mismo conjunto de núcleos: no hay afinidad.

— AngryHacker

¿Su almacenamiento es SAN o local?

— Eric Higgins el

@EricHiggins Solo un conjunto local de discos duros RAID.

— AngryHacker

Como dijiste, este tipo de espera indica que la aplicación no está al día con SQL Server. Ahora, lo que eso realmente significa es que SQL Server no puede enviar los datos a través de la red tan rápido como quisiera.

Puede haber dos causas subyacentes:

La aplicación está escrita de manera ineficiente y no procesa las filas lo suficientemente rápido.
La red está al máximo.

Si la aplicación en sí es demasiado lenta, no habrá ningún impacto significativo en el rendimiento de otras consultas. Si, por otro lado, la tubería es demasiado pequeña, otras consultas tampoco pueden enviar sus resultados y tienen que esperar.

En el último caso, sin embargo, tendría todas las conexiones esperando en ASYNC_NETWORK_IO. Debería poder ver ese impacto claramente.

— Sebastian Meine
fuente

Para la viñeta 1. La recuperación de datos se realiza a través de ADO.NET utilizando un código estándar: por lo var dataSet = new DataSet(); var da = new SqlDataAdapter(command); da.Fill(dataSet); tanto, no estoy seguro de qué podría ser lento.

— AngryHacker

Para el punto de viñeta 2. La aplicación se encuentra en el mismo cuadro que SQL y la conexión se realiza mediante el método de memoria compartida. Teóricamente, eso debería ser súper rápido.

— AngryHacker