|
Uporabniške povezave SQLSERVER Splošna statistikaUporabniške povezave SQL instance v števcu zmogljivosti mu ustrezajo V števcu zmogljivosti se lahko sklicujete tudi na TCPv4Connections, vzpostavljene
Na računalniku, ki ima samo storitev SQLSERVER,Vzpostavljene povezave TCPV4 & Mssql uporabniške povezaveTa dva parametra sta v osnovi sinhronizirana in se v naslednji testni vsebini imenujeta število povezav
To število povezav je omejeno, podobno kot največje število omejitev sočasnosti. Ko je ta omejitev dosežena, poizvedbe postanejo neodzivne, tudi če so na voljo prosti CPU, IO in MEM viri (nekatera, ne pa vsa poizvedba so prizadeta)
Največja vrednost vzpostavljenih TCPV4 povezav in Mssql uporabniških povezav je odvisna od naslednjih dejavnikov
a. Kompleksnost izvršilne izjave je povezana: bolj kot je izjava kompleksna, manjše je največje število povezav (ta učinek je zelo pomemben)
b. Povezana je s sočasnostjo niti zahteve,
10 procesov, vsak proces odpre 5.000 niti za zahtevo,SELECT getdate()Izjava je že opuščena, ko doseže približno 4000 (kolikor razumem, čeprav veliko tem ni zahtevalo virov, je število zahtev veliko, kar prav tako vpliva).
10 procesov, vsak proces odpre 1000 niti za zahtevo, SELECT getdate()Izjave lahko dosežejo več kot 10.000.
c. Povezana je s pogostostjo zahtev za niti
Če vsaka nit izvede poizvedbo in se ustavi za 0-10.000 milisekund, bo zavzela manj povezav, kot če ni suspendirana
d. V testu je bilo ugotovljeno tudi, da bi nekatere nezaprte povezave povzročile napihnjenost števca, kar ni bilo obravnavano
10 procesov, vsak proces odpre 1000 niti zahtev, nato naključno prekine (0 do 10 sekund) po vsaki poizvedbi na strežniku. Rezultati testa so naslednji:
Izvedba:IZBERI * IZ [sistem]. [dbo]. [DBA_alert](ta poizvedba vrne 200 vrstic, največje število povezav je 700 in problem se začne izdajati)
Ko število povezav doseže 700, se začnejo pojavljati nekatere napake, pri 1200 pa se pojavi veliko napak, pri čemer se število povezav okoli 1800 zatakne in ne narašča več. Napake in počasne povezave so pogoste
Izvedba:SELECT getdate()Čas stavka(Največje število povezav je 3500 in problem se začne)
Ko število povezav doseže 3500, nekatere začnejo poročati o napakah, najvišji tlak doseže okoli 11000, število povezav pa se še vedno počasi povečuje. Napake in počasni izpadi povezave
Zaključek je: pod danimi pritisknimi pogoji: najlažje za izvedboNajvečje število povezav je lahko do 3500, ko SELECT getdate() izvede SELECT * FROM [system]. [dbo]. [DBA_alert] je največje število povezav lahko le do 700. Časovni izpad poizvedbe nastopi, ko imajo CPU, IO in MEM veliko neaktivnih virov.
V produkcijskem okolju pritiska 10*1000 niti ni mogoče doseči, vendar je SQL bolj kompleksen kot testno okolje.
Sočasna številkaOzko grlo ni posledica pasovne širine mojega računalnika ali strežniške kartice
Da dokažemo zgoraj navedeno. Naredil sem naslednje teste, npr. dbo.run2 v primeru velike sočasnosti;
ALTER proc [dbo]. [tek2]
kot
nastavi nocount on
Izberi getdate()
deklariraj @i int
množica @i=0
medtem ko @i<1000 Ko je ta vrednost 1000, je največje število povezav približno 1300, in ko je ta vrednost 10, je normalno, da dosežemo 5000.
začetek
VSTAVI v [pubs]. [dbo]. [tb_test] ([name]) vrednosti (newid())
množica @i=@i+1
konec
Pojdi
Število ciklov sprememb ne vpliva na povratni rezultat, torej je pritisk na promet omrežnih kartic enak, vendar bo eden hitro potekel in drugega je vedno mogoče preveriti, tako da je vpliv pasovne širine omrežnih kartic na obeh straneh odpravljen.
Vsebina napake, ko je največje število povezav zaustavljeno:
NetStat-An rezultat, ko je največje število povezav zablokirano (močno uveljavljeno):
Testni program izvaja diagram, ko je največje število povezav zaustavljeno:
Vredno je omeniti:Povezava z napakami ali časovnimi omejitvami ni enakomerna in bo skoncentrirana v nekaterih procesih, kar pomeni, da lahko nekateri procesi vedno delujejo normalno, drugi del pa bo dolgo poročal o napakah (to nima nobene zveze z vrstnim redom zagona procesov, kolikor razumem, nekateri procesi imajo vire, lahko nadaljujejo normalno delovanje, medtem ko so drugi procesi v nitih v izvirnih virih prekinjeni in ne morejo zahtevati novih virov, bodo še naprej poročali o napakah). Kot je prikazano na zgornji sliki, sta 2. in 7. proces začela imeti veliko število časovnih omejitev, drugi procesi pa so še naprej delovali. Na strežniku se poizvedbe lahko pojavijo kot neprizadete ali manj prizadete s strani nekaterih računalnikov, nekatere naprave pa so močno prizadete.
Zaključek: Čeprav je zgornja meja uporabniških povezav SQLSERVER-a povezana z vrsto pogojev, je še vedno mogoče oceniti in napovedati ozko grlo; ko je ta zgornja meja dosežena, bo veliko poizvedb počasnih in časovnih omejitev (čeprav CPU, IO). MEM, promet se lahko pojavi tudi, ko so viri neuporabljeni). Pravzaprav bo sprememba nekaterih TCP parametrov povečala to zgornjo mejo, morda pa bom kasneje napisal dodatke
|
Objavljeno na 26. 11. 2014 15:11:08
|
|
|
|
