|
SQLSERVERI kasutajaühendused SQL-instantsi üldised statistilised kasutajaühendused jõudlusloenduris vastavad sellele Võid vaadata ka TCPv4Connections Established jõudlusloenduris
Masinal, kus on ainult SQLSERVER-teenus,TCPV4 ühendused loodud && Mssql UserConnectionsNeed kaks parameetrit on põhimõtteliselt sünkroniseeritud ja neid nimetatakse järgmises testisisus ühenduste arvuks
See ühenduste arv on piiratud, sarnaselt maksimaalsele samaaegsuse piirangutele. Kui see piir saavutatakse, muutuvad päringud reageerimatuks, isegi kui on vabu CPU, IO ja MEM ressursse (mõned, mitte kõik päringud on mõjutatud)
TCPV4 Connections Established && Mssql UserConnections maksimaalne väärtus sõltub järgmistest teguritest
a. Täitmislause keerukus on seotud, mida keerulisem avaldus, seda väiksem on maksimaalne ühenduste arv (see efekt on väga oluline)
b. See on seotud taotluse lõime paralleelsusega,
10 protsessi, iga protsess avab 5000 lõime, et pärida,SELECT getdate()See avaldus on juba umbes 4000 juures hüljatud (minu arusaam on, et kuigi paljud teemad pole ressursse küsinud, on taotluste arv suur, mis samuti mõjutab).
10 protsessi, iga protsess avab 1000 lõime, et pärida, SELECT getdate()Avaldused võivad ulatuda üle 10 000.
c. See on seotud lõimepäringute sagedusega
Kui iga lõim käivitab päringu ja peatub 0–10 000 millisekundiks, võtab see vähem ühendusi kui siis, kui seda ei peatata
d. Testis leiti ka, et mõned sulgemata ühendused põhjustavad loenduri paisumise, mida ei arutatud
10 protsessi, iga protsess avab 1000 päringulõime, juhuslikult peatub (0 kuni 10 sekundit) pärast iga päringut serveris. Testitulemused on järgmised:
Täitmine:VALI * SÜSTEEMIST. [dbo]. [DBA_alert]väide (see päring tagastab 200 rida, maksimaalne ühenduste arv on 700 ja probleem hakkab tekkima)
Kui ühenduste arv jõuab 700-ni, hakatakse teatama mõningatest vigadest ning kell 1200 ilmneb suur hulk vigu ning ühenduste arv umbes 1800 jääb kinni ega tõuse enam. Vigu ja aeglaseid ühendusi on rohkelt
Täitmine:SELECT getdate()Karistusaeg(Maksimaalne ühenduste arv on 3500 ja probleem algab)
Kui ühenduste arv jõuab 3500-ni, hakkavad mõned neist teatama vigadest, kõrgeim rõhk ulatub umbes 11000-ni ning ühenduste arv kasvab endiselt aeglaselt. Vead ja aeglased ühenduse katkemised
Järeldus on: antud rõhutingimustes: kõige lihtsam teostadaMaksimaalne ühenduste arv võib olla kuni 3500, kui SELECT getdate() ja käivita SELECT * FROM [system]. [dbo]. [DBA_alert] avaldus, võib maksimaalne ühenduste arv olla kuni 700. Päringu ajapiirang tekib siis, kui CPU-l, IO-l ja MEM-il on palju tühiseisvaid ressursse.
Tootmiskeskkonnas ei ole võimalik saavutada 10*1000 lõime survet, kuid SQL on testkeskkonnast keerukam.
Samaaegne arvKitsaskoht ei tulene minu arvuti või serveri võrgukaardi ribalaiusest
Et seda tõestada. Tegin järgmised testid, suure paralleelsuse korral exec dbo.run2;
ALTER proc [dbo]. [run2]
kui
Sea nocount peal
vali getdate()
deklareeri @i int.
komplekt @i=0
samal ajal kui @i<1000 Kui see väärtus on 1000, on maksimaalne ühenduste arv umbes 1300, ja kui see väärtus on 10, on tavapärane jõuda 5000-ni.
Alusta
SISESTA [pubidesse]. [dbo]. [tb_test] ([name]) väärtused (newid())
komplekt @i=@i+1
Lõpp
mine
Vahetustsüklite arv ei mõjuta tagastustulemust, st surve võrgukaardi liiklusele on sama, kuid üks aegub kiiresti ja teine saab alati kontrollida, nii et võrgukaartide ribalaiuse mõju mõlemal poolel saab elimineerida.
Veasisu, kui maksimaalne ühenduste arv on seiskunud:
NetStat – tulemus, kui maksimaalne ühenduste arv jääb kinni (tugevalt kehtestatud):
Testi programmi käivitusdiagrammi, kui maksimaalne ühenduste arv on seiskunud:
Tasub märkida:Seos vigade või ajapiirangutega ei ole ühtlane ja koondub mõnes protsessis, st mõned protsessid töötavad alati normaalselt ning teine osa raporteerib vigu pikka aega (see ei ole seotud protsesside algusjärjekorraga, minu arusaam on, et mõnel protsessil on ressursse, need võivad jätkata normaalset tööd, samas kui teised protsessid algsete ressursside lõimedes on ennetõrjutud ega saa uusi ressursse taotleda, esitavad pidevalt vigu üles). Nagu ülaloleval joonisel näidatud, hakkasid 2. ja 7. protsessid kogema palju timeout'e ning teised protsessid jätkasid tööd. Serveris võivad päringud tunduda mõjutamata või vähem mõjutatud mõne masina poolt ning mõned masinad on oluliselt mõjutatud.
Kokkuvõte: Kuigi SQLSERVERi kasutajate ühenduste ülemine piir on seotud mitmete tingimustega, on siiski võimalik hinnata ja ennustada pudelikaela – kui see ülempiir saavutatakse, on suur hulk päringuid aeglasemaks ja ajapiiranguid (kuigi CPU, IO. MEM, liiklus võib tekkida ka siis, kui ressursid on tühikäigul). Tegelikult suurendab mõne TCP parameetri muutmine seda ülemist piiri ja ma võin hiljem lisasid kirjutada
|
Postitatud 26.11.2014 15:11:08
|
|
|
|
