|
SQLSERVER-brugerforbindelser De generelle StatistikBrugerforbindelser for SQL-instansen i performance-tælleren svarer til den Du kan også henvise til TCPv4Connections Established i performance-tælleren
På en maskine med kun SQLSERVER-tjenesten,TCPV4-forbindelser etableret & Mssql UserConnectionsDisse to parametre er grundlæggende synkroniserede og kaldes antallet af forbindelser i det følgende testindhold
Dette antal forbindelser er begrænset, svarende til det maksimale antal samtidige grænser. Når denne grænse nås, vil det få forespørgsler til at blive uresponsive, selvom der er ledige CPU-, IO- og MEM-ressourcer (nogle, men ikke alle, forespørgsler påvirkes)
Den maksimale værdi af TCPV4 Connections Established & Mssql UserConnections afhænger af følgende faktorer
a. Kompleksiteten af eksekveringsudsagnet er relateret, jo mere kompleks udsagnet er, desto mindre er det maksimale antal forbindelser (denne effekt er meget vigtig)
b. Det er relateret til trådens samtidighed i anmodningen,
10 processer, hver proces åbner 5.000 tråde for at anmode om,SELECT getdate()Udsagnet er allerede opgivet, når det når omkring 4000 (min forståelse er, at selvom mange tråde ikke har anmodet om ressourcer, er antallet af anmodninger stort, hvilket også har en betydning).
10 processer, hver proces åbner 1000 tråde for at anmode om, SELECT getdate()Kontoudtog kan nå op på mere end 10.000.
c. Det er relateret til hyppigheden af trådforespørgsler
Hvis hver tråd kører en forespørgsel og pauser i 0-10.000 millisekunder, vil den optage færre forbindelser, end hvis den ikke er suspenderet
d. I testen blev det også konstateret, at nogle ulukkede forbindelser ville få tælleren til at blive oppustet, hvilket ikke blev diskuteret
10 processer, hver proces åbner 1000 anmodningstråde, pauser tilfældigt (0 til 10 sekunder) efter hver forespørgsel på serveren. Testresultaterne er som følger:
Udførelse:VÆLG * FRA [system]. [DBO]. [DBA_alert]sætning (denne forespørgsel returnerer 200 linjer, og det maksimale antal forbindelser er 700, og problemet begynder at blive udstedt)
Når antallet af forbindelser når 700, begynder nogle fejl at blive rapporteret, og ved 1200 begynder et stort antal fejl at dukke op, og antallet af forbindelser omkring 1800 sidder fast og stiger ikke længere. Fejl og træge forbindelser er talrige
Udførelse:SELECT getdate()Sætningstid(Det maksimale antal forbindelser er 3500, og problemet starter)
Når antallet af forbindelser når 3500, begynder nogle af dem at rapportere fejl, og det højeste tryk når omkring 11.000, og antallet af forbindelser stiger stadig langsomt. Fejl og langsomme forbindelsesudbrud
Konklusionen er: under givne trykforhold: det simpleste at udføreDet maksimale antal forbindelser kan være op til 3500, når SELECT getdate(), og udfører SELECT * FROM [system]. [DBO]. [DBA_alert]-sætningen, kan det maksimale antal forbindelser kun være op til 700. Forespørgselstimeout opstår, når CPU, IO og MEM alle har et stort antal inaktive ressourcer.
I produktionsmiljøet kan presset fra 10*1000 tråde ikke opnås, men SQL vil være mere komplekst end testmiljøet.
Samtidige numreFlaskehalsen skyldes ikke båndbredden på min computer eller servernetværkskort
For at bevise ovenstående. Jeg lavede følgende tests, exec dbo.run2 i tilfælde af stor samtidighed;
ALTER proc [dbo]. [run2]
som
Sæt nocount på
Vælg getdate()
Oplys @i int
sæt @i=0
mens @i<1000 Når denne værdi er 1000, er det maksimale antal forbindelser omkring 1300, og når denne værdi er 10, er det normalt at nå 5000.
Begynd
INSERT INTO [pubs]. [DBO]. [tb_test] ([navn]) værdier (newid())
sæt @i=@i+1
slut
Gå
Antallet af ændringscyklusser vil ikke påvirke returresultatet, det vil sige, presset på netværkskortets trafik er det samme, men den ene vil hurtigt gå ud af tid, og den anden kan altid kontrolleres, så påvirkningen af netværkskortenes båndbredde på begge sider kan elimineres.
Fejlindhold, når det maksimale antal forbindelser er stoppet:
Netstat – et resultat når det maksimale antal forbindelser sidder fast (stærkt etableret):
Testprogram, der kører diagram, når det maksimale antal forbindelser er gået i stå:
Det er værd at bemærke:Forbindelsen mellem fejl eller timeouts er ikke jævn og vil være koncentreret i nogle processer, det vil sige, at nogle processer altid kan køre normalt, og den anden del vil rapportere fejl i lang tid (det har intet at gøre med startrækkefølgen af processerne, min forståelse er, at nogle processer har ressourcer, kan fortsætte med at fungere normalt, mens andre processer i trådene i de oprindelige ressourcer bliver præempet og ikke kan ansøge om nye ressourcer, og vil fortsætte med at rapportere fejl gentagne gange). Som vist i figuren ovenfor begyndte den 2. og 7. proces at få et stort antal timeouts, og andre processer fortsatte med at fungere. På serveren kan forespørgsler fremstå som upåvirkede eller mindre påvirkede af nogle maskiner, og nogle maskiner er betydeligt påvirkede.
Konklusion: Selvom den øvre grænse for SQLSERVER-brugerforbindelser er relateret til en række betingelser, er det stadig muligt at estimere og forudsige flaskehalsen; når denne øvre grænse nås, vil der være et stort antal forespørgsler, der er langsomme og tidsafbrydelser (selvom CPU, IO. MEM, kan trafik også forekomme, når der er inaktive ressourcer). Faktisk vil ændring af nogle TCP-parametre øge denne øvre grænse, og jeg kan skrive supplementer senere
|
Opslået på 26/11/2014 15.11.08
|
|
|
|
