Pourquoi les types d'attente async_network_io se produisent-ils?

La semaine dernière, quelque chose d'étrange s'est produit dans notre base de données. Tout d'un coup, l'application a été bloquée pour nos utilisateurs qui n'ont pas pu enregistrer de nouvelles entités, etc. Après avoir regardé le moniteur d'activité de SQL Server (2008 avec le mode de compatibilité 2005), j'ai vu les trois entrées suivantes:

Après un certain temps, les utilisateurs ont obtenu un délai de connexion. Lorsque j'ai tué le processus 64, ils pouvaient à nouveau enregistrer normalement.

Le problème est que les entités qu'ils ont essayé d'enregistrer pendant le bloc ont été insérées dans la base de données plus d'une fois (jusqu'à 3 fois) même s'il existe du code qui devrait empêcher cela de se produire (colonne de numéro qui doit être unique mais sans contrainte) ... la vérification a lieu dans le code).

Nous utilisons Entity Framework 6.0.

• L'un de vous sait-il pourquoi et quand ces types d'attente ASYNC_NETWORK_IO se produisent et comment les éviter?
• Et que signifient-ils exactement?

ASYNC_NETWORK_IOindique en quelque sorte que l'application cliente ne traite pas les résultats aussi rapidement que SQL Server les alimente. Cela peut être dû à un problème avec l'application cliente ou avec la connexion réseau entre le serveur et l'application cliente.

Veuillez vous référer à un article de Thomas LaRock

L'attente ASYNC_NETWORK_IO indique que l'un des deux scénarios se produit. Le premier scénario est que la session (c'est-à-dire SPID) attend que l'application cliente traite l'ensemble de résultats et renvoie un signal à SQL Server indiquant qu'elle est prête à traiter plus de données. La seconde est qu'il peut y avoir un problème de performances réseau.

ou ce post de Joe Sack

Comme vous le savez peut-être déjà, les types d'attente ASYNC_NETWORK_IO (vu dans SQL 2005) et NETWORKIO (vu dans SQL 2000) sont associés à une application appelante qui ne traite pas les résultats assez rapidement à partir de SQL Server ou est associée à un problème de performances réseau .

Puisque vous utilisez entity framework ce message de Brent Ozar, cela peut aussi être utile

En regardant les statistiques d'attente pour ces requêtes, j'ai vu qu'il y avait beaucoup de ASYNC_NETWORK_IO - souvent 1000+ millisecondes. Cela n'avait aucun sens non plus! Comment une requête avec si peu de temps processeur et si peu de lectures peut-elle prendre autant de temps? Ce n'est pas comme si l'application demandait des millions de lignes et ne pouvait pas consommer les résultats assez rapidement.

Il existe certaines idées fausses concernant le type d'attente ASYNC_NETWORK_IO, principalement en raison du nom qui indique le problème de réseau, mais la raison de ce type d'attente est assez rare.

Des attentes ASYNC_NETWORK_IO excessives peuvent se produire dans deux scénarios:

1. La session doit attendre que l'application cliente traite les données reçues de SQL Server pour envoyer le signal à SQL Server qu'elle peut accepter de nouvelles données pour le traitement. Il s'agit d'un scénario courant qui peut refléter une mauvaise conception d'application et est la cause la plus fréquente de valeurs de type d'attente ASYNC_NETWORK_IO excessives.

   Cela implique d'étudier l'application qui provoque les valeurs excessives du type d'attente ASYNC_NETWORK_IO et souvent de coordonner avec les développeurs d'applications qui l'ont créée.

2. La bande passante réseau est maximisée. Un Ethernet obstrué entraînera la lente transmission des données dans les deux sens depuis l'application. Cela, en soi, dégradera l'efficacité de l'application.

Beaucoup plus de détails peuvent être trouvés sur cette page