Has visto este tipo de espera antes, ¿no es así? Bueno, ciertamente es un tipo de espera que ha causado mucha confusión. El enfoque inmediato generalmente se le da a la palabra "RED", pero la mayoría de las veces no tiene nada que ver con la red.
El tipo de espera ASYNC_NETWORK_IO normalmente producirá dos tipos de síntomas, el primero es que la carga de trabajo de la sesión está esperando que la aplicación cliente correspondiente reconozca o procese un conjunto determinado de datos e informe a SQL Server que está listo para procesar o reconocer más datos. El segundo síntoma es que puede haber un problema de rendimiento en la red entre la aplicación y la instancia de la base de datos. Detrás de escena, SQL Server mantiene los datos en un búfer de salida hasta que se recibe un reconocimiento del cliente que determina si el consumo de datos es completo. ASYNC_NETWORK_IO es una señal reveladora de que la aplicación carece de eficiencia en la lectura de los datos que requiere de su base de datos de back-end. La red subyacente también puede tener problemas que pueden producir esperas más prolongadas mientras se procesan los datos y las señales se envían de regreso desde el cliente al servidor.
Las posibles causas de esta espera incluyen:
- El código de la aplicación no recupera los datos correctamente
- Grandes conjuntos de datos solicitados por el cliente
- Exceso de filtrado de datos que ocurre en el lado del cliente o de la aplicación
- Dispositivos de red mal configurados como tarjetas, conmutadores, etc.
En un alto nivel, un DBA puede querer verificar estas cosas:
- Revise el código de la aplicación y asegúrese de que la aplicación esté leyendo los datos de manera correcta/eficiente. Por ejemplo, ¿su aplicación está retirando una gran cantidad de filas solo para procesar una fila a la vez?
- ¿Filtrado de datos innecesario en el lado del cliente/aplicación? Limite las filas.
Si los elementos anteriores se verifican, pero los problemas con ASYNC_NETWORK_IO persisten, esto puede deberse a la red. Aquí hay algunas cosas que puede investigar:
- Inspeccione el enlace de comunicación de la red entre la aplicación y la instancia de la base de datos back-end y verifique el ancho de banda.
- Utilice sys.dm_io_virtual_file_stats para probar la latencia general de la red debido a la carga o la distancia
- Examine la configuración de la NIC en el servidor de la base de datos para asegurarse de que no falten fallas o configuraciones.
El TIPO DE ESPERA ASYNC_NETWORK_IO podría ser un problema relacionado con la red, pero a menudo puede deberse a una aplicación cliente que no está procesando sus datos de manera eficiente. Si este último es realmente el caso, entonces esta es una oportunidad para que DBAS y los desarrolladores trabajen juntos para comprender lo que la aplicación realmente necesita en beneficio del rendimiento de la base de datos de back-end. Garantizar que la mayor parte del filtrado de datos se realice dentro de SQL Server es una buena práctica que se puede lograr a través de vistas o condiciones más específicas en la sintaxis de la transacción.
Si bien hay muchas formas de monitorear y medir la espera ASYNC_NETWORK_IO mediante el uso de DMV catalogados y eventos extendidos en SQL Server, alentamos a nuestra comunidad de administradores de bases de datos de SQL Server a buscar Spotlight Cloud de Quest, que proporciona eficiencia para determinar la causa raíz del tipo de espera. consumo durante un período de tiempo histórico.
