Vous avez déjà vu ce type d'attente, n'est-ce pas ? Eh bien, c'est certainement un type d'attente qui a causé beaucoup de confusion. L'accent immédiat est généralement mis sur le mot "RÉSEAU", mais la plupart du temps, cela n'a rien à voir avec le réseau !
Le type d'attente ASYNC_NETWORK_IO produira généralement deux types de symptômes, le premier étant que la charge de travail de la session attend que l'application cliente correspondante reconnaisse/traite un ensemble de données donné et fasse savoir à SQL Server qu'il est prêt à traiter/reconnaître plus de données. Le deuxième symptôme est qu'il peut y avoir un problème de performances dans le réseau entre l'application et l'instance de base de données. Dans les coulisses, SQL Server conserve les données dans un tampon de sortie jusqu'à ce qu'un accusé de réception soit reçu du client déterminant si la consommation de données est Achevée. ASYNC_NETWORK_IO est un signe révélateur que l'application manque d'efficacité dans la lecture des données dont elle a besoin à partir de sa base de données principale. Le réseau sous-jacent peut également avoir des problèmes qui peuvent produire des temps d'attente plus longs pendant le traitement des données et les signaux sont renvoyés du client au serveur.
Les causes possibles de cette attente incluent :
- Le code de l'application ne récupère pas correctement les données
- Grands ensembles de données demandés par le client
- Filtrage excessif des données se produisant côté client ou côté application
- Périphériques réseau mal configurés tels que cartes, commutateurs, etc.
À un niveau élevé, un administrateur de base de données peut souhaiter vérifier ces éléments :
- Examinez le code de l'application et assurez-vous que l'application lit les données correctement/efficacement. Par exemple, votre application extrait-elle un grand nombre de lignes uniquement pour traiter une ligne à la fois ?
- Filtrage inutile des données côté client/application ? Limitez les lignes.
Si les éléments ci-dessus sont vérifiés, mais que les problèmes avec ASYNC_NETWORK_IO persistent, cela peut être dû au réseau. Voici quelques éléments sur lesquels vous pouvez vous pencher :
- Inspectez le lien de communication réseau entre l'application et l'instance de base de données principale et vérifiez la bande passante.
- Utilisez sys.dm_io_virtual_file_stats pour tester le réseau pour la latence générale due à la charge ou à la distance
- Examinez la configuration de la carte réseau sur le serveur de base de données pour vous assurer qu'aucun défaut et/ou paramètre ne manque.
Le TYPE D'ATTENTE ASYNC_NETWORK_IO peut en effet être un problème lié au réseau, mais il peut souvent être dû à une application cliente qui ne traite pas ses données efficacement. Si c'est effectivement le cas, c'est l'occasion pour DBAS et les développeurs de travailler ensemble pour comprendre ce dont l'application a vraiment besoin dans l'intérêt des performances de la base de données principale. S'assurer que la plupart des filtrages de données sont effectués dans SQL Server est une bonne pratique qui peut être réalisée via des vues ou des conditions where plus spécifiques dans la syntaxe de la transaction.
Bien qu'il existe de nombreuses façons de surveiller et de mesurer l'attente ASYNC_NETWORK_IO grâce à l'utilisation de DMV catalogués et d'événements étendus dans SQL Server, nous encourageons notre communauté d'administrateurs de base de données SQL Server à consulter le Spotlight Cloud de Quest, qui permet de déterminer efficacement la cause première du type d'attente. consommation sur une période historique.
