|
SQLSERVER-Benutzerverbindungen Die General StatisticsUser Connections der SQL-Instanz im Leistungszähler entsprechen ihr Du kannst auch auf TCPv4Connections Established im Performance-Zähler nachschlagen
Auf einer Maschine mit nur dem SQLSERVER-Service,TCPV4-Verbindungen eingerichtet & Mssql UserConnectionsDiese beiden Parameter sind im Grunde synchronisiert und werden als Anzahl der Verbindungen im folgenden Testinhalt bezeichnet
Diese Anzahl der Verbindungen ist begrenzt, ähnlich wie die maximale Anzahl der Nebenlaufbahngrenzen. Wenn dieses Limit erreicht ist, reagieren Abfragen nicht mehr, selbst wenn freie CPU-, IO- und MEM-Ressourcen vorhanden sind (einige, aber nicht alle Anfragen sind betroffen).
Der maximale Wert von TCPV4 Connections Established & Mssql UserConnections hängt von folgenden Faktoren ab
a. Die Komplexität der Ausführungsanweisung hängt damit zusammen: Je komplexer die Anweisung, desto kleiner die maximale Anzahl der Verbindungen (dieser Effekt ist sehr wichtig)
b. Sie steht im Zusammenhang mit der Thread-Nebenwahl der Anfrage,
10 Prozesse, jeder Prozess öffnet 5.000 Threads, um anzufordern,SELECT getdate()Die Aussage wird bereits aufgegeben, wenn sie etwa 4000 erreicht (meines Wissens haben viele Threads zwar keine Ressourcen angefordert, aber die Anzahl der Anfragen ist groß, was ebenfalls Auswirkungen hat).
10 Prozesse, jeder Prozess öffnet 1000 Threads, um anzufordern, SELECT getdate()Auszüge können mehr als 10.000 erreichen.
c. Sie hängt mit der Häufigkeit der Thread-Anfragen zusammen
Wenn jeder Thread eine Abfrage ausführt und für 0–10.000 Millisekunden pausiert, benötigt er weniger Verbindungen als wenn er nicht ausgesetzt ist
d. Im Test wurde außerdem festgestellt, dass einige nicht geschlossene Verbindungen dazu führen würden, dass der Zähler aufgeblasen wird, was jedoch nicht diskutiert wurde
10 Prozesse, jeder Prozess öffnet 1000 Anfrage-Threads, pausiert zufällig (0 bis 10 Sekunden) nach jeder Abfrage auf dem Server. Die Testergebnisse sind wie folgt:
Hinrichtung:SELECT * FROM [System]. [dbo]. [DBA_alert]Anweisung (diese Abfrage liefert 200 Zeilen, die maximale Anzahl der Verbindungen beträgt 700, und das Problem wird ausgegeben)
Wenn die Anzahl der Verbindungen 700 erreicht, werden einige Fehler gemeldet, und bei 1200 treten viele Fehler auf, sodass die Anzahl der Verbindungen um 1800 steckt und nicht mehr steigt. Fehler und träge Verbindungen sind zahlreich
Hinrichtung:SELECT getdate()Satzzeit(Die maximale Anzahl der Verbindungen beträgt 3500 und das Problem beginnt)
Wenn die Anzahl der Verbindungen 3500 erreicht, beginnen einige von ihnen, Fehler zu melden, und der höchste Druck erreicht etwa 11.000, während die Anzahl der Verbindungen weiterhin langsam ansteigt. Fehler und träge Verbindungsausbrüche
Die Schlussfolgerung lautet: unter gegebenen Druckbedingungen: am einfachsten durchzuführenDie maximale Anzahl der Verbindungen kann bis zu 3500 betragen, wenn SELECT getdate() ausgeführt wird und SELECT * FROM [System] ausgeführt wird. [dbo]. [DBA_alert]-Anweisung, darf die maximale Anzahl der Verbindungen nur bis zu 700 betragen. Ein Abfrage-Timeout tritt auf, wenn CPU, IO und MEM alle über eine große Anzahl von leeren Ressourcen verfügen.
In der Produktionsumgebung kann der Druck von 10*1000 Threads nicht erreicht werden, aber SQL ist komplexer als die Testumgebung.
Gleichzeitige NummerDer Engpass wird nicht durch die Bandbreite meines Computers oder meiner Server-Netzwerkkarte verursacht
Um das oben Genannte zu beweisen. Ich habe folgende Tests gemacht: exec dbo.run2 im Fall großer Nebenwahl;
ALTER löst [dbo] aus. [Lauf2]
als
Setze Nocount auf
getdate() auswählen
Declare @i int
Menge @i=0
während @i<1000 Wenn dieser Wert 1000 beträgt, beträgt die maximale Anzahl der Verbindungen etwa 1300, und wenn dieser Wert 10 beträgt, ist es normal, 5000 zu erreichen.
Beginnen
INSERT INTO [Pubs]. [dbo]. [tb_test] ([name]) Werte (newid())
Set @i=@i+1
Ende
los
Die Anzahl der Wechselzyklen beeinflusst das Rückgabeergebnis nicht, das heißt, der Druck auf den Netzwerkkartenverkehr ist gleich, aber einer wird schnell abgelaufen und der andere kann immer überprüft werden, sodass die Bandbreite der Netzwerkkarten auf beiden Seiten eliminiert werden kann.
Fehlerinhalt, wenn die maximale Anzahl von Verbindungen gestoppt ist:
Netstat – Ein Ergebnis, wenn die maximale Verbindungszahl feststeckt (stark etabliert):
Testprogramm-Diagramm läuft, wenn die maximale Anzahl von Verbindungen gestoppt ist:
Es ist erwähnenswert:Die Verbindung mit Fehlern oder Timeouts ist nicht gleichmäßig und konzentriert sich auf einige Prozesse, das heißt, einige Prozesse können immer normal laufen, während der andere Teil lange Zeit Fehler meldet (das hat nichts mit der Startreihenfolge der Prozesse zu tun, meines Wissens haben einige Prozesse Ressourcen und können normal weiterarbeiten, während andere Prozesse in den ursprünglichen Ressourcen unterbrochen werden und keine neuen Ressourcen beantragen können, sondern wiederholt Fehler melden). Wie in der obigen Abbildung gezeigt, begannen der 2. und 7. Prozess, eine große Anzahl von Timeouts zu haben, und andere Prozesse arbeiteten weiter. Auf dem Server können Abfragen von einigen Maschinen als unbeeinflusst oder weniger betroffen erscheinen, und einige Rechner sind deutlich betroffen.
Fazit: Obwohl die obere Grenze der SQLSERVER-Benutzerverbindungen mit einer Reihe von Bedingungen zusammenhängt, ist es dennoch möglich, den Engpass abzuschätzen und vorherzusagen; wenn diese obere Grenze erreicht ist, wird es eine große Anzahl von langsamen Abfragen und Timeouts geben (obwohl CPU, IO. MEM-Verkehr kann auch auftreten, wenn Ressourcen ungenutzt sind). Tatsächlich erhöht das Ändern einiger TCP-Parameter dieses obere Limit, und ich schreibe vielleicht später Ergänzungen
|
Veröffentlicht am 26.11.2014 15:11:08
|
|
|
|
