Lorsqu'elle est connectée à notre serveur de production (SQL Server 2008, machine très puissante), cette instruction SELECT prend 2 secondes , crachant tous les champs (4 Mo de données au total).
SELECT TOP (30000) *
FROM person
WITH(NOLOCK);
À partir de n'importe quelle autre boîte sur le même réseau (connexion en utilisant l'authentification SQL ou l'authentification Windows), la même requête prend 1 minute, 8 secondes .
Je teste avec cette déclaration très simple pour illustrer qu'il ne s'agit pas d'un problème d'indexation ou d'un problème lié aux requêtes. (Nous avons actuellement des problèmes de performances avec toutes les requêtes ...)
Les rangées viennent en morceaux, et pas en même temps. J'obtiens mes premières lignes instantanément, puis j'attends plus d'une minute pour que les lots de lignes entrent.
Voici les statistiques client de la requête, lorsqu'elle est exécutée à partir de la boîte distante:
Query Profile Statistics
Number of INSERT, DELETE and UPDATE statements 0
Rows affected by INSERT, DELETE, or UPDATE statements 0
Number of SELECT statements 2
Rows returned by SELECT statements 30001
Number of transactions 0
Network Statistics
Number of server roundtrips 3
TDS packets sent from client 3
TDS packets received from server 1216
Bytes sent from client 266
Bytes received from server 4019800
Time Statistics
Client processing time 72441 ms (72 seconds)
Total execution time 72441 ms
Wait time on server replies 0
Nous pouvons voir que le «temps de traitement client» est égal au temps d'exécution total.
Quelqu'un sait-il quelles mesures je peux prendre pour diagnostiquer pourquoi le transfert des données réelles prend du temps?
Existe-t-il un paramètre de configuration SQL qui restreint ou limite la vitesse de transfert de données entre les machines?
la source
Réponses:
Votre problème est définitivement lié au réseau, basé sur vos informations. En tant que tel, il doit être traité avec des professionnels du réseau (ce n'est pas moi).
Choses qui pourraient aider:
Le serveur Web est-il dans le même sous-réseau que le serveur SQL?
Y a-t-il des routeurs / ponts, etc. entre eux?
Pas beaucoup de changements possibles sur le serveur SQL:
Vous utilisez une taille par défaut: consultez vos statistiques: "Paquets TDS reçus du serveur 1216" (4MB / 1K = 4KB). Oui, la taille du tampon TDS peut être modifiée: voir dans google: "TDS protocol batch size"
Bonne discussion sur le sujet: "la taille des paquets réseau de sql détermine-t-elle vraiment le trafic aller-retour?"
Cependant, la modification de la taille du boîtier TDS aura (inévitablement) des effets imprévisibles et ne devrait être utilisée en production que dans des cas exceptionnels.
Un changement d'architecture ou l'introduction de la mise en cache des données sur le niveau intermédiaire serait également utile.
la source
Ce problème est maintenant résolu.
C'était un problème de réseau, et la boîte SQL utilisait une carte NIC de 100 Mo / s , au lieu d'une carte NIC de 10 Go / s ...
Un changement de configuration réseau pour utiliser la bonne carte réseau a résolu le problème. Nous obtenons maintenant des performances similaires pour toutes les requêtes de la zone Production SQL et des autres zones du réseau.
Merci à tous pour votre aide.
la source
À la lecture initiale, il semble que vous rencontriez des problèmes de latence du réseau. Avez-vous regardé certains des compteurs Network Perfmon? Ceux-ci peuvent vous donner une indication de ce qui se passe avec le réseau.
Citation de Quels compteurs Perfmon dois-je surveiller et que signifie chacun d'eux?
la source
Quelques questions préliminaires: 1) Le serveur a un client SQL sur Prod. configuration de la machine serveur, non? Donc, si vous faites la même requête à partir du client situé sur la même machine, elle sera terminée en 2 secondes? Avez-vous essayé de faire ça? Est-ce vraiment 2 secondes? 2) Vous avez mentionné que la configuration de votre environnement de production a été modifiée (ou que le serveur de production a été déplacé vers un autre réseau / la reconstruction totale du serveur est terminée), non? Quel était le temps de consommation des requêtes dans l'ancien environnement de production?
Par curiosité: c'est un exemple de la requête? ou la formulation exacte de la requête? La requête ne contient vraiment PAS de clause WHERE? D'accord avec moi que c'est très inhabituel .. La table a un index clusterisé ou est un tas? Le tableau contient combien de lignes au total? Le tableau est fortement fragmenté? Par curiosité: pourquoi avoir choisi SELECT TOP NNN? Pourquoi ne pas SET ROWCOUNT NNN - puis SELECT *? Cette requête est émise combien de fois par le client par jour? 1? 100? 1MLN? Les données sous-jacentes sont statiques ou dynamiques et ont-elles beaucoup changé? Combien (0,01% par jour? 1% par jour? 10% par jour?) La sortie de la requête est traitée par programme? (pas par un utilisateur?) Pourquoi n'est-il pas mis en cache / pas stocké sur le niveau intermédiaire? merci, Alexei
la source