Le type d'attente ASYNC_NETWORK_IO doit-il inquiéter?

En regardant la liste des procédures stockées qui prennent beaucoup de temps à exécuter, on se démarque comme causant le plus d'attente. Cependant, la majeure partie de cette attente (81%) est ASYNC_NETWORK_IO et je sais pourquoi: la procédure stockée transfère environ 400 Mo d'informations.

Dans la documentation, il indique que la cause de ASYNC_NETWORK_IO est que le client ne peut pas suivre le flot de données et c'est probablement vrai. Je ne sais pas comment faire pour que le client continue car il ne fait qu'appeler la procédure stockée via un ADO.NET et ensuite simplement traiter l'ensemble de données.

Donc, étant donné ces informations, dois-je m'inquiéter du type d'attente ASYNC_NETWORK_IO pour cette procédure? Cela a-t-il réellement un effet sur les performances du serveur?

Informations supplémentaires:

Je suis sur le Service Pack 2 de SQL Server 2005.
L'application client est sur la même case que SQL Server (je sais, je sais ... mais je ne peux rien y faire).

— AngryHacker
source

La meilleure façon de penser à ce type d'attente est qu'il n'y a rien dans votre requête qui la cause - c'est le retour de données au client. Vous verrez également que beaucoup d'entre vous ont lié des tables dans Access. Selon votre application cliente, une possibilité consiste à diviser les données en petits morceaux ou à renvoyer simplement moins de données. Si ce n'est pas une option, vous serez probablement limité dans ce que vous pouvez faire pour la réduire.

— JNK

L'application cliente se connecte-t-elle à l'aide de la mémoire partagée ou TCP / IP? L'application client et SQL Server partagent-ils le même ensemble de cœurs de processeur, ou utilisez-vous une technique de masquage d'affinité pour les séparer?

— Jon Seigel

C'est le type de connexion par défaut - rien de spécial - donc il utilise la mémoire partagée. Les deux applications utilisent le même ensemble de cœurs - il n'y a aucune affinité.

— AngryHacker

Votre stockage est-il SAN ou local?

— Eric Higgins

@EricHiggins Juste un ensemble local de disques durs RAIDés.

— AngryHacker

Comme vous l'avez dit, ce type d'attente indique que l'application ne suit pas SQL Server. Maintenant, cela signifie vraiment que SQL Server ne peut pas envoyer les données sur le réseau aussi rapidement qu'il le souhaiterait.

Il peut y avoir deux causes sous-jacentes:

L'application est écrite de manière inefficace et ne traite pas les lignes assez rapidement.
Le réseau est au maximum.

Si l'application elle-même est trop lente, il n'y aura pas ou pas d'impact significatif sur les performances des autres requêtes. Si par contre le tube est trop petit, les autres requêtes ne peuvent pas envoyer leurs résultats non plus et doivent attendre.

Dans ce dernier cas cependant, vous auriez toutes les connexions en attente sur ASYNC_NETWORK_IO. Vous devriez pouvoir voir clairement cet impact.

— Sebastian Meine
source

Pour le point 1. La récupération des données se fait via ADO.NET en utilisant le code standard: var dataSet = new DataSet(); var da = new SqlDataAdapter(command); da.Fill(dataSet); Je ne sais donc pas exactement ce qui pourrait être lent.

— AngryHacker

Pour le point 2. L'application est sur la même case que SQL et la connexion se fait via la méthode de mémoire partagée. Donc, théoriquement, cela devrait être super rapide.

— AngryHacker