|
Conexiuni de utilizator SQLSERVER Conexiunile General StatisticsUser ale instanței SQL din contorul de performanță corespund acesteia De asemenea, puteți consulta TCPv4Connections Established în contorul de performanță
Pe o mașină cu doar serviciul SQLSERVER,Conexiuni TCPV4 stabilite & conexiuni utilizator MssqlAcești doi parametri sunt practic sincronizați și sunt denumiți numărul de conexiuni în conținutul următor de test
Acest număr de conexiuni este limitat, similar cu numărul maxim de limite de concurență. Când această limită este atinsă, interogările vor deveni nereceptive chiar dacă există resurse libere pentru CPU, IO și MEM (unele, nu toate interogările sunt afectate)
Valoarea maximă a TCPV4 Connections Established & Mssql UserConnections depinde de următorii factori
a. Complexitatea instrucțiunii de execuție este legată, cu cât afirmația este mai complexă, cu atât numărul maxim de conexiuni este mai mic (acest efect este foarte important)
b. Este legat de concurența firului de substanță a cererii,
10 procese, fiecare proces deschide 5.000 de fire pentru a solicita,SELECT getdate()Declarația este deja abandonată când ajunge la aproximativ 4000 (din câte înțeleg, deși multe fire nu au solicitat resurse, numărul cererilor este mare, ceea ce are și un impact).
10 procese, fiecare proces deschide 1000 de fire pentru a solicita, SELECT getdate()Extrasele pot ajunge la peste 10.000.
c. Este legat de frecvența solicitărilor de tip thread
Dacă fiecare fir rulează o interogare și se oprește între 0 și 10.000 de milisecunde, va ocupa mai puține conexiuni decât dacă nu este suspendat
d. În test, s-a constatat că unele conexiuni neînchise ar cauza umflarea contorului, lucru care nu a fost discutat
10 procese, fiecare proces deschide 1000 de fire de solicitare, pauză aleatorie (0 până la 10 secunde) după fiecare interogare pe server. Rezultatele testului sunt următoarele:
Execuție:SELECT * FROM [system]. [dbo]. [DBA_alert](această interogare returnează 200 de linii, iar numărul maxim de conexiuni este 700 și problema începe să apară)
Când numărul de conexiuni ajunge la 700, încep să fie raportate unele erori, iar la ora 12:00 apar un număr mare de erori, iar numărul de conexiuni din jurul valorii 18:00 rămâne blocat și nu mai crește. Erorile și conexiunile lente sunt numeroase
Execuție:SELECT getdate()Durata sentinței(Numărul maxim de conexiuni este 3500 și problema începe)
Când numărul de conexiuni ajunge la 3500, unele dintre ele încep să raporteze erori, iar cea mai mare presiune ajunge în jur de 11000, iar numărul de conexiuni continuă să crească lent. Erori și defecțiuni lente ale conexiunii
Concluzia este: în condiții de presiune date: cel mai simplu de realizatNumărul maxim de conexiuni poate ajunge până la 3500 când SELECT getdate() și execută SELECT * FROM [sistem]. [dbo]. [DBA_alert], numărul maxim de conexiuni poate fi doar până la 700. Timeout-ul interogării apare atunci când CPU, IO și MEM au un număr mare de resurse inactive.
În mediul de producție, presiunea de 10*1000 de fire de execuție nu poate fi atinsă, dar SQL va fi mai complex decât mediul de testare.
Număr concurentBlocajul nu este cauzat de lățimea de bandă a calculatorului sau a plăcii de rețea a serverului meu
Pentru a demonstra cele de mai sus. Am făcut următoarele teste, exec dbo.run2 în cazul unei concurențe mari;
ALTER proc [dbo]. [run2]
ca
setează nocount pe
selectează getdate()
declară @i int
set @i=0
în timp ce @i<1000 Când această valoare este 1000, numărul maxim de conexiuni este aproximativ 1300, iar când această valoare este 10, este normal să se ajungă la 5000.
Încep
INSERAȚI ÎN [pubs]. [dbo]. [tb_test] ([nume]) valori (newid())
set @i=@i+1
Sfârșit
Du-te
Numărul ciclurilor de schimbare nu va afecta rezultatul returnării, adică presiunea asupra traficului plăcii de rețea este aceeași, dar unul va expira rapid, iar celălalt poate fi întotdeauna verificat, astfel încât impactul lățimii de bandă al plăcilor de rețea pe ambele părți poate fi eliminat.
Conținutul erorii când numărul maxim de conexiuni este blocat:
NetStat-An rezultat când numărul maxim de conexiuni este blocat (puternic stabilit):
Programul de testare care rulează diagrama atunci când numărul maxim de conexiuni este blocat:
Merită menționat:Legătura cu erorile sau timeout-urile nu este uniformă și va fi concentrată în unele procese, adică unele procese pot rula întotdeauna normal, iar cealaltă parte va raporta erori pentru mult timp (nu are legătură cu ordinea de pornire a proceselor, din câte înțeleg unele procese au resurse, pot continua să funcționeze normal, în timp ce alte procese din firele de execuție din resursele originale sunt preemptate și nu pot aplica pentru resurse noi, vor continua să raporteze erori în mod repetat). După cum se arată în figura de mai sus, al doilea și al șaptelea proces au început să aibă un număr mare de timeout-uri, iar alte procese au continuat să funcționeze. Pe server, interogările pot apărea ca neafectate sau mai puțin afectate de unele mașini, iar unele mașini sunt semnificativ afectate.
Concluzie: Deși limita superioară a conexiunilor utilizatorilor SQLSERVER este legată de o serie de condiții, este totuși posibil să se estimeze și să se prezică blocajul; când această limită superioară este atinsă, vor exista un număr mare de interogări lente și timeout-uri (deși CPU, IO). MEM, traficul poate apărea și atunci când există resurse inactive). De fapt, schimbarea unor parametri TCP va crește această limită superioară, iar voi putea scrie suplimente mai târziu
|
Postat pe 26.11.2014 15:11:08
|
|
|
|
