|
Connexions utilisateur SQLSERVER Les connexions General StatisticsUser de l’instance SQL dans le compteur de performance lui correspondent Vous pouvez également vous référer à TCPv4Connections Established dans le compteur de performance
Sur une machine avec uniquement le service SQLSERVER,Connexions TCPV4 établies & Connexions utilisateurs MssqlCes deux paramètres sont essentiellement synchronisés et sont désignés comme le nombre de connexions dans le contenu du test suivant
Ce nombre de connexions est limité, similaire au nombre maximal de limites de concurrence. Lorsque cette limite est atteinte, cela rend les requêtes non réactives même s’il y a des ressources CPU, E/S et MEM libres (certaines, pas toutes, sont affectées)
La valeur maximale de TCPV4 Connections Established & Mssql UserConnections dépend des facteurs suivants
a. La complexité de l’instruction d’exécution est liée : plus l’instruction est complexe, plus le nombre maximal de connexions est petit (cet effet est très important)
b. Elle est liée à la concurrence de threads de la requête,
10 processus, chaque processus ouvre 5 000 threads pour demander,SELECT getdate()La déclaration est déjà abandonnée lorsqu’elle atteint environ 4000 (d’après ce que je comprends, bien que de nombreux threads n’aient pas demandé de ressources, le nombre de requêtes est important, ce qui a aussi un impact).
10 processus, chaque processus ouvre 1000 threads pour demander, SELECT getdate()Les relevés peuvent dépasser 10 000.
c. Elle est liée à la fréquence des requêtes de thread
Si chaque thread exécute une requête et s’arrête de 0 à 10 000 millisecondes, il occupera moins de connexions que s’il n’est pas suspendu
d. Lors du test, il a également été constaté que certaines connexions non fermées provoquaient un gonflement du compteur, ce qui n’a pas été abordé
10 processus, chaque processus ouvre 1000 threads de requêtes, met en pause aléatoire (0 à 10 secondes) après chaque requête sur le serveur. Les résultats du test sont les suivants :
Exécution :SELECT * FROM [system]. [dbo]. [DBA_alert](cette requête retourne 200 lignes, et le nombre maximal de connexions est de 700, et le problème commence à apparaître)
Lorsque le nombre de connexions atteint 700, certaines erreurs commencent à être signalées, et à 12h00, un grand nombre d’erreurs apparaissent, et le nombre de connexions autour de 1800 reste bloqué et n’augmente plus. Les erreurs et les connexions lentes sont nombreuses
Exécution :SELECT getdate()Durée de la peine(Le nombre maximal de connexions est de 3500 et le problème commence)
Lorsque le nombre de connexions atteint 3500, certaines commencent à signaler des erreurs, et la pression maximale atteint environ 11000, et le nombre de connexions continue d’augmenter lentement. Erreurs et ruptures de connexion lentes
La conclusion est : sous des conditions de pression données : la plus simple à réaliserLe nombre maximal de connexions peut atteindre 3500 lorsque SELECT getdate(), et exécute SELECT * FROM [système]. [dbo]. [DBA_alert], le nombre maximal de connexions ne peut être que jusqu’à 700. Le délai d’attente de requête se produit lorsque le CPU, les IO et le MEM disposent tous d’un grand nombre de ressources inactives.
En environnement de production, la pression sur 10 threads ne peut pas être atteinte, mais SQL sera plus complexe que l’environnement de test.
Numéro concurrentLe goulot d’étranglement n’est pas causé par la bande passante de mon ordinateur ou de la carte réseau serveur
Pour prouver ce qui précède. J’ai fait les tests suivants : exécutif dbo.run2 en cas de grande concurrence ;
ALTER proc [dbo]. [run2]
comme
Mettre nocount sur
sélectionne getdate()
déclare @i int
Ensemble @i=0
tandis que @i<1000 Lorsque cette valeur est 1000, le nombre maximal de connexions est d’environ 1300, et lorsque cette valeur est 10, il est normal d’atteindre 5000.
Début
INSÉRER DANS [pubs]. [dbo]. [tb_test] ([nom]) valeurs (newid())
Ensemble @i=@i+1
Fin
Vas-y
Le nombre de cycles de changement n’affectera pas le résultat de retour, c’est-à-dire que la pression sur le trafic de la carte réseau est la même, mais l’un expirera rapidement et l’autre pourra toujours être vérifié, ce qui permet d’éliminer l’impact de la bande passante des cartes réseau des deux côtés.
Contenu d’erreur lorsque le nombre maximal de connexions est bloqué :
NetStat - Résultat lorsque le nombre maximal de connexions est bloqué (fortement établi) :
Programme de test exécutant un diagramme lorsque le nombre maximal de connexions est bloqué :
Il convient de noter :Le lien avec les erreurs ou les délais d’attente n’est pas uniforme, et sera concentré dans certains processus, c’est-à-dire que certains processus peuvent toujours fonctionner normalement, et l’autre partie signalera des erreurs pendant longtemps (cela n’a rien à voir avec l’ordre de départ des processus, d’après ce que je comprends, certains processus ont des ressources, peuvent continuer à fonctionner normalement, tandis que d’autres processus dans les threads des ressources originales sont préemptés et ne peuvent pas s’appliquer à de nouvelles ressources, rapportent régulièrement des erreurs). Comme montré dans la figure ci-dessus, les 2e et 7e processus ont commencé à avoir un grand nombre de délais d’attente, et d’autres processus ont continué à fonctionner. Sur le serveur, les requêtes peuvent apparaître comme non affectées ou moins affectées par certaines machines, et certaines machines sont significativement affectées.
Conclusion : Bien que la limite supérieure des connexions utilisateurs SQLSERVER soit liée à une série de conditions, il est tout de même possible d’estimer et de prédire le goulot d’étranglement ; lorsque cette limite supérieure sera atteinte, il y aura un grand nombre de requêtes lentes et de délais d’attente (bien que le CPU, l’IO). MEM, le trafic peut aussi survenir lorsqu’il y a des ressources inactives). En fait, modifier certains paramètres TCP augmentera cette limite supérieure, et je pourrais écrire des suppléments plus tard
|
Publié sur 26/11/2014 15:11:08
|
|
|
|
