|
SQLSERVER-användaranslutningar De allmänna statistikanvändarkopplingarna för SQL-instansen i prestandaräknaren motsvarar den Du kan också hänvisa till TCPv4Connections Established i prestandaräknaren
På en maskin med endast SQLSERVER-tjänsten,TCPV4-anslutningar etablerade & Mssql UserConnectionsDessa två parametrar är i princip synkroniserade och kallas antalet anslutningar i följande testinnehåll
Detta antal anslutningar är begränsat, liknande det maximala antalet samtidighetsgränser. När denna gräns nås kommer det att göra att frågor blir oresponsiva även om det finns lediga CPU-, IO- och MEM-resurser (vissa, inte alla frågor påverkas)
Det maximala värdet av TCPV4 Connections Established & Mssql UserConnections beror på följande faktorer
a. Komplexiteten i exekveringssatsen är relaterad, ju mer komplex satsen är, desto mindre blir det maximala antalet anslutningar (denna effekt är mycket viktig)
b. Den är relaterad till trådens samtidighet i begäran,
10 processer, varje process öppnar 5 000 trådar för att begära,SELECT getdate()Uttalandet överges redan när det når cirka 4000 (min förståelse är att även om många trådar inte har begärt resurser, är antalet förfrågningar stort, vilket också påverkar).
10 processer, varje process öppnar 1000 trådar för att begära, SELECT getdate()Kontoutdrag kan nå mer än 10 000.
c. Det är relaterat till frekvensen av trådförfrågningar
Om varje tråd kör en fråga och pausar i 0–10 000 millisekunder, tar den upp färre anslutningar än om den inte är avstängd
d. I testet fann man också att vissa oslutna anslutningar skulle orsaka att räknaren blåstes upp, vilket inte diskuterades
10 processer, varje process öppnar 1000 förfrågningstrådar, pausar slumpmässigt (0 till 10 sekunder) efter varje fråga på servern. Testresultaten är följande:
Genomförande:VÄLJ * FRÅN [system]. [dbo]. [DBA_alert]sats (denna fråga returnerar 200 rader, och det maximala antalet anslutningar är 700 och problemet börjar utfärdas)
När antalet anslutningar når 700 börjar vissa fel rapporteras, och vid 1200 börjar ett stort antal fel dyka upp, och antalet anslutningar runt 1800 fastnar och ökar inte längre. Fel och tröga anslutningar är vanliga
Genomförande:SELECT getdate()Strafftid(Det maximala antalet anslutningar är 3500 och problemet startar)
När antalet anslutningar når 3500 börjar några av dem rapportera fel, och det högsta trycket når cirka 11 000, och antalet anslutningar ökar fortfarande långsamt. Fel och tröga anslutningsutbrytningar
Slutsatsen är: under givna tryckförhållanden: det enklaste att utföraDet maximala antalet anslutningar kan vara upp till 3500 när SELECT getdate(), och kör SELECT * FROM [system]. [dbo]. [DBA_alert]-satsen, kan det maximala antalet anslutningar endast vara upp till 700. Frågetimeout inträffar när CPU, IO och MEM alla har ett stort antal inaktiva resurser.
I produktionsmiljön kan trycket av 10*1000 trådar inte nås, men SQL kommer att vara mer komplext än testmiljön.
Samtidigt antalFlaskhalsen orsakas inte av bandbredden på min dator eller mitt servernätverkskort
För att bevisa ovanstående. Jag gjorde följande tester, exec dbo.run2 vid stor samtidighet;
ALTER aktiverar [dbo]. [run2]
som
Sätt nocount på
Välj getdate()
Deklarera @i int
Sätt @i=0
medan @i<1000 När detta värde är 1000 är det maximala antalet anslutningar cirka 1300, och när detta värde är 10 är det normalt att nå 5000.
Börja
INFOGA IN [pubar]. [dbo]. [tb_test] ([namn]) värden (newid())
set @i=@i+1
slut
Gå
Antalet bytescykler påverkar inte returresultatet, det vill säga trycket på nätverkskortets trafik är detsamma, men den ena går snabbt ut och den andra kan alltid kontrolleras, så bandbredden på nätverkskorten på båda sidor kan elimineras.
Felinnehåll när det maximala antalet anslutningar är stillastående:
Netstat – ett resultat när maximalt anslutningsantal fastnar (starkt etablerat):
Testprogram kör diagram när det maximala antalet anslutningar är stillastående:
Det är värt att notera:Kopplingen till fel eller timeouts är inte jämn, och kommer att koncentreras till vissa processer, det vill säga, vissa processer kan alltid köras normalt, och den andra delen rapporterar fel under lång tid (det har inget att göra med startordningen på processerna, min förståelse är att vissa processer har resurser, kan fortsätta fungera normalt, medan andra processer i trådarna i de ursprungliga resurserna avbryts och inte kan ansöka om nya resurser, och fortsätter att rapportera fel upprepade gånger). Som visas i figuren ovan började den andra och sjunde processen få ett stort antal timeouts, och andra processer fortsatte att fungera. På servern kan frågor visas som opåverkade eller mindre påverkade av vissa maskiner, och vissa maskiner påverkas avsevärt.
Slutsats: Även om den övre gränsen för SQLSERVER-användaranslutningar är relaterad till en serie villkor, är det fortfarande möjligt att uppskatta och förutsäga flaskhalsen, och när denna övre gräns nås kommer det att bli ett stort antal långsamma frågor och timeouts (även om CPU, IO. MEM, trafik kan också uppstå när det finns lediga resurser). Faktum är att ändra vissa TCP-parametrar kommer att öka denna övre gräns, och jag kan skriva tillägg senare
|
Publicerad på 2014-11-26 15:11:08
|
|
|
|
