|
SQLSERVER lietotāju savienojumi Tam atbilst SQL instances vispārīgie statistikas lietotāju savienojumi veiktspējas skaitītājā Varat arī skatīt TCPv4Connections Established veiktspējas skaitītājā
Datorā, kurā ir tikai SQLSERVER pakalpojums,Izveidoti TCPV4 savienojumi && Mssql lietotāja savienojumiŠie divi parametri pamatā ir sinhronizēti un tiek saukti par savienojumu skaitu nākamajā testa saturā
Šis savienojumu skaits ir ierobežots, līdzīgi kā maksimālais vienlaicīguma ierobežojumu skaits. Kad šis ierobežojums ir sasniegts, vaicājumi nereaģēs pat tad, ja ir brīvi CPU, IO un MEM resursi (daži, ne visi vaicājumi tiek ietekmēti)
TCPV4 izveidoto savienojumu && Mssql lietotāju savienojumu maksimālā vērtība ir atkarīga no šādiem faktoriem
a. Izpildes paziņojuma sarežģītība ir saistīta, jo sarežģītāks ir paziņojums, jo mazāks ir maksimālais savienojumu skaits (šis efekts ir ļoti svarīgs)
b. Tas ir saistīts ar pieprasījuma pavediena vienlaicīgumu,
10 procesi, katrs process atver 5,000 pavedienus, lai pieprasītu,SELECT getdate()Paziņojums jau ir atmests, kad tas sasniedz aptuveni 4000 (mana izpratne ir tāda, ka, lai gan daudzi pavedieni nav pieprasījuši resursus, pieprasījumu skaits ir liels, kas arī ietekmē).
10 procesi, katrs process atver 1000 pavedienus, lai pieprasītu, SELECT getdate()Paziņojumi var sasniegt vairāk nekā 10 000.
c. Tas ir saistīts ar pavedienu pieprasījumu biežumu
Ja katrs pavediens palaiž vaicājumu un pauzē 0–10 000 milisekundes, tas aizņems mazāk savienojumu nekā tad, ja tas nav apturēts
d. Testā tika arī konstatēts, ka daži neslēgti savienojumi izraisītu skaitītāja piepūšanu, kas netika apspriests
10 procesi, katrs process atver 1000 pieprasījuma pavedienus, nejauši pauzē (no 0 līdz 10 sekundēm) pēc katra vaicājuma serverī Testa rezultāti ir šādi:
Izpilde:ATLASIET * FROM [sistēma]. [DBO]. [DBA_alert]priekšraksts (šis vaicājums atgriež 200 rindiņas, un maksimālais savienojumu skaits ir 700, un problēma sāk tikt izsniegta)
Kad savienojumu skaits sasniedz 700, sāk ziņot par dažām kļūdām, un 1200 sāk parādīties liels skaits kļūdu, un savienojumu skaits ap 1800 ir iestrēdzis un vairs nepalielinās. Kļūdas un lēni savienojumi ir bagātīgi
Izpilde:SELECT getdate()Soda laiks(Maksimālais savienojumu skaits ir 3500 un problēma sākas)
Kad savienojumu skaits sasniedz 3500, daži no tiem sāk ziņot par kļūdām, un augstākais spiediens sasniedz aptuveni 11000, un savienojumu skaits joprojām lēnām pieaug. Kļūdas un lēni savienojuma izplūdumi
Secinājums ir šāds: noteiktos spiediena apstākļos: visvienkāršāk veiktMaksimālais savienojumu skaits var būt līdz 3500, kad SELECT getdate() un izpilda SELECT * FROM [sistēma]. [DBO]. [DBA_alert] priekšrakstu, maksimālais savienojumu skaits var būt tikai līdz 700. Vaicājuma taimauts notiek, ja CPU, IO un MEM ir liels skaits dīkstāves resursu.
Ražošanas vidē nevar sasniegt 10 * 1000 pavedienu spiedienu, bet SQL būs sarežģītāks nekā testa vide.
Vienlaicīgs numursSastrēgumu neizraisa datora vai servera tīkla kartes joslas platums
Lai pierādītu iepriekš minēto. Es veicu šādus testus, exec dbo.run2 lielas vienlaicīgas gadījumā;
ALTER proc [dbo]. [skrējiens2]
kā
Iestatīt nocount ieslēgtu
Izvēlieties getdate()
deklarēt @i int
iestatīt @i=0
kamēr @i<1000 Ja šī vērtība ir 1000, maksimālais savienojumu skaits ir aptuveni 1300, un, ja šī vērtība ir 10, ir normāli sasniegt 5000.
Sākt
IEVIETOJIET [krogos]. [DBO]. [tb_test] ([nosaukums]) vērtības (newid())
Iestatiet @i=@i+1
beigas
Iet
Izmaiņu ciklu skaits neietekmēs atgriešanās rezultātu, tas ir, spiediens uz tīkla kartes trafiku ir vienāds, bet viens ātri iestāsies un otru vienmēr var pārbaudīt, tāpēc var novērst tīkla karšu joslas platuma ietekmi abās pusēs.
Kļūdas saturs, ja maksimālais savienojumu skaits ir apstājies:
netstat-rezultāts, kad maksimālais savienojumu skaits ir iestrēdzis (stipri noteikts):
Testa programmas darbības shēma, kad maksimālais savienojumu skaits ir apstājies:
Ir vērts atzīmēt:Savienojums ar kļūdām vai taimautiem nav vienmērīgs, un tas tiks koncentrēts dažos procesos, tas ir, daži procesi vienmēr var darboties normāli, un otra daļa ilgu laiku ziņos par kļūdām (tam nav nekāda sakara ar procesu sākuma secību, mana izpratne ir tāda, ka dažiem procesiem ir resursi, tie var turpināt strādāt normāli, bet citi procesi sākotnējo resursu pavedienos ir apturēti un nevar pieteikties jauniem resursiem, turpinās atkārtoti ziņot par kļūdām) Kā parādīts iepriekš redzamajā attēlā, 2. un 7. procesam sākās liels skaits taimautu, un citi procesi turpināja darboties. Serverī vaicājumi var parādīties kā neietekmēti vai mazāk ietekmēti no dažiem datoriem, un daži datori ir būtiski ietekmēti.
Secinājums: Lai gan SQLSERVER lietotāju savienojumu augšējā robeža ir saistīta ar virkni apstākļu, joprojām ir iespējams novērtēt un prognozēt vājo kaklu, kad šī augšējā robeža ir sasniegta, būs liels skaits vaicājumu lēni un taimauts (lai gan CPU, IO. MEM, satiksme var rasties arī tad, ja ir dīkstāves resursi). Faktiski, mainot dažus TCP parametrus, palielināsies šī augšējā robeža, un es varu rakstīt papildinājumus vēlāk
|
Publicēts 26.11.2014 15:11:08
|
|
|
|
