Énorme ressource de type "E / S réseau" attend
Nous avons une application interne, développée dans WinDev, qui utilise une base de données Microsoft SQL Server 2012 SP2 (build 11.0.5058) fonctionnant sur Windows Server 2008R2.
Nous rencontrons des problèmes de performances. Dans le même temps, Activity Monitor affiche un grand nombre d'attentes de type "E/S réseau", où "énorme" dans ce cas est un temps d'attente cumulé de 7 millions de secondes pour un serveur qui est en fonction depuis moins de 6 jours:
La connectivité réseau elle-même est très bien, le serveur est connecté avec 10G tandis que le client est soit un bureau physique connecté avec 1 Go ou des serveurs Bureau à distance avec 10G. La surveillance du réseau ne montre aucune saturation de liaison, ni aucun autre problème de réseau. CPU, RAM et disque I/O sont également très bien.
D'après ce que j'ai lu sur les attentes d'E/S réseau, cela concerne les enregistrements renvoyés par une requête qui ne sont pas consommés par les clients. J'ai donc tendance à penser que le problème est dans l'application, mais j'ai du mal à ce que les développeurs enquêtent sur cela (pas qu'ils ne veulent pas le faire, mais ils sont assez occupés et il semble qu'ils n'aient aucune idée de la racine cause et comment le résoudre)
Donc les questions:
Ai-je raison de penser que le problème de performances est lié à ces attentes d'E/S réseau?
quel indice pourrais-je fournir à l'équipe de développement pour l'aider à identifier la cause?
à part la correction de l'application, y a-t-il un réglage fin que je peux faire sur le serveur SQL lui-même pour atténuer le problème?
- Arrêtez d'utiliser Moniteur d'activité
- Utilisez sp_WhoIsActive pour comprendre ce qui se passe réellement
Il pourrait s'agir de sauvegardes, auquel cas il y a pas beaucoup de choses que vous pouvez faire qui n'implique pas de mises à niveau matérielles (peut-être que 1 Go iSCSI n'était pas une si bonne idée ...)
Cela peut être du code côté client consommant des données RBAR (pensez à des boucles foreach pour chaque ligne entrant), ou demander beaucoup de lignes en une seule fois ( c'est là que les requêtes de pagination peuvent aider).
Ça pourrait être autre chose!
Pour avoir une idée de ce que votre serveur attend le plus, rendez-vous sur firstresponderkit.org - divulgation complète, je contribue à ce projet open source - et saisissez sp_BlitzFirst (ou, bon sang, prenez-les tous).
Vous pouvez exécuter cette commande pour consulter vos statistiques d'attente dans leur ensemble, depuis le démarrage.
EXEC sp_BlitzFirst @SinceStartup = 1
Ou ceci pour obtenir un échantillon de statistiques d'attente lors d'un ralentissement.
EXEC sp_BlitzFirst @Seconds = 30, @ExpertMode = 1
J'espère que cela t'aides!
Surveillez les requêtes provenant de leur application, y compris les attentes (vous pouvez le faire avec les événements étendus), puis exécutez les mêmes requêtes depuis sqlcmd ou SSMS (mais pas avec les résultats vers la grille) et comparez. Cela devrait vous aider à faire la distinction entre les applications qui ne peuvent pas consommer les résultats assez rapidement et un réseau qui ne peut pas transmettre les données assez rapidement.
Je ne sais pas si les "E/S réseau" dans le moniteur d'activité ne sont mappées que sur ASYNC_NETWORK_IO, mais sur un réseau comme le vôtre, cette attente n'est presque certainement due qu'à des retards dans la consommation des clients.