|
SQLSERVER Gebruikersverbindingen De General StatisticsUser Connections van de SQL-instantie in de prestatieteller corresponderen ermee Je kunt ook verwijzen naar TCPv4Connections Established in de prestatieteller
Op een machine met alleen de SQLSERVER-service,TCPV4-verbindingen tot stand gebracht & Mssql UserConnectionsDeze twee parameters zijn in feite gesynchroniseerd en worden aangeduid als het aantal verbindingen in de volgende testinhoud
Dit aantal verbindingen is beperkt, vergelijkbaar met het maximale aantal gelijktijdige limieten. Wanneer deze limiet wordt bereikt, zullen queries niet meer reageren, zelfs als er vrije CPU-, IO- en MEM-bronnen zijn (sommige, niet alle queries worden beïnvloed)
De maximale waarde van TCPV4 Connections Established, & Mssql UserConnections hangt af van de volgende factoren
a. De complexiteit van de uitvoeringsinstructie hangt samen, hoe complexer de instructie, hoe kleiner het maximale aantal verbindingen (dit effect is erg belangrijk)
b. Het heeft betrekking op de thread-gelijktijdigheid van het verzoek,
10 processen, elk proces opent 5.000 threads om te verzoeken,SELECT getdate()De verklaring wordt al verlaten wanneer het ongeveer 4000 bereikt (voor zover ik weet is dat hoewel veel threads geen resources hebben aangevraagd, het aantal verzoeken groot is, wat ook invloed heeft).
10 processen, elk proces opent 1000 threads om aan te vragen, SELECT getdate()Afschriften kunnen meer dan 10.000 bereiken.
c. Het hangt samen met de frequentie van threadverzoeken
Als elke thread een query uitvoert en pauzeert van 0-10.000 milliseconden, neemt hij minder verbindingen in beslag dan wanneer hij niet is onderbroken
d. In de test werd ook vastgesteld dat sommige niet-gesloten verbindingen ervoor zorgden dat de teller werd opgeblazen, wat niet werd besproken
10 processen, elk proces opent 1000 verzoekthreads, pauzeert willekeurig (0 tot 10 seconden) na elke query op de server. De testresultaten zijn als volgt:
Uitvoering:SELECTEER * UIT [systeem]. [dbo]. [DBA_alert]stelling (deze query geeft 200 regels terug, en het maximale aantal verbindingen is 700 en het probleem begint te ontstaan)
Wanneer het aantal verbindingen 700 bereikt, beginnen er fouten te worden gemeld, en bij 1200 verschijnen er veel fouten, waardoor het aantal verbindingen rond 1800 blijft hangen en stijgt niet meer. Fouten en trage verbindingen zijn talrijk
Uitvoering:SELECT getdate()Straftijd(Het maximale aantal verbindingen is 3500 en het probleem begint)
Wanneer het aantal verbindingen 3500 bereikt, beginnen sommige fouten te rapporteren, en de hoogste druk bereikt ongeveer 11.000, terwijl het aantal verbindingen nog steeds langzaam stijgt. Fouten en trage verbindingsuitbraken
De conclusie is: onder gegeven drukcondities: het eenvoudigst uit te voerenHet maximale aantal verbindingen kan tot 3500 zijn wanneer SELECT getdate() en SELECT * FROM [systeem] uitvoert. [dbo]. [DBA_alert]-statement, het maximale aantal verbindingen kan slechts tot 700 zijn. Query-timeout treedt op wanneer CPU, IO en MEM allemaal een groot aantal inactieve bronnen hebben.
In de productieomgeving is de druk van 10*1000 threads niet te bereiken, maar SQL zal complexer zijn dan de testomgeving.
Gelijktijdig aantalDe bottleneck wordt niet veroorzaakt door de bandbreedte van mijn computer of servernetwerkkaart
Om het bovenstaande te bewijzen. Ik heb de volgende tests gedaan: exec dbo.run2 in het geval van grote gelijktijdigheid;
ALTER proc [dbo]. [run2]
als
Zet Nocount op
selecteer getdate()
Verklaar @i int
stel @i=0
terwijl @i<1000 Wanneer deze waarde 1000 is, is het maximale aantal verbindingen ongeveer 1300, en wanneer deze waarde 10 is, is het normaal om 5000 te bereiken.
begin
INSERT INTO [publicaties]. [dbo]. [tb_test] ([naam]) waarden (newid())
set @i=@i+1
einde
Ga
Het aantal wisselcycli beïnvloedt het retourresultaat niet, dat wil zeggen, de druk op het netwerkkaartverkeer is hetzelfde, maar de ene loopt snel uit en de andere kan altijd worden gecontroleerd, waardoor de impact van de bandbreedte van de netwerkkaarten aan beide zijden kan worden geëlimineerd.
Foutinhoud wanneer het maximale aantal verbindingen vastloopt:
Netstat - Een resultaat wanneer het maximale aantal verbindingen vastzit (sterk vastgesteld):
Testprogramma dat een diagram draait wanneer het maximale aantal verbindingen vastloopt:
Het is het vermelden waard:De verbinding met fouten of time-outs is niet gelijkmatig en zal geconcentreerd zijn in sommige processen, dat wil zeggen, sommige processen kunnen altijd normaal draaien, en het andere deel zal lange tijd fouten rapporteren (het heeft niets te maken met de startvolgorde van de processen, voor zover ik weet hebben sommige processen resources, kunnen ze normaal blijven werken, terwijl andere processen in de threads in de oorspronkelijke resources worden onderbroken en geen nieuwe resources kunnen aanvragen, en herhaaldelijk fouten blijven rapporteren). Zoals te zien in de bovenstaande figuur, begonnen de 2e en 7e processen een groot aantal time-outs te krijgen, en andere processen bleven werken. Op de server kunnen queries onaangetast of minder beïnvloed worden door sommige machines, en sommige machines zijn aanzienlijk beïnvloed.
Conclusie: Hoewel de bovengrens van SQLSERVER-gebruikersverbindingen gerelateerd is aan een reeks voorwaarden, is het nog steeds mogelijk om de bottleneck te schatten en te voorspellen; wanneer deze bovengrens wordt bereikt, zullen er veel langzame queries en time-outs zijn (hoewel CPU, IO. MEM, verkeer kan ook plaatsvinden wanneer er ongebruikte bronnen zijn). Sterker nog, het wijzigen van enkele TCP-parameters zal deze bovengrens verhogen, en ik schrijf misschien later supplementen
|
Geplaatst op 26-11-2014 15:11:08
|
|
|
|
