|
Používateľské pripojenia SQLSERVER Všeobecné štatistiky: Používateľské prepojenia SQL inštancie v čítači výkonu mu zodpovedajú Môžete tiež použiť TCPv4Connections Established vo výkonnostnom čítači
Na stroji, ktorý má iba službu SQLSERVER,Nadviazané TCPV4 pripojenia & Mssql UserConnectionsTieto dva parametre sú v podstate synchronizované a v nasledujúcom testovacom obsahu sa označujú ako počet pripojení
Tento počet spojení je obmedzený, podobne ako maximálny počet limitov súbežnosti. Keď sa tento limit dosiahne, spôsobí, že dotazy prestanú reagovať, aj keď sú k dispozícii voľné CPU, IO a MEM zdroje (niektoré, nie všetky dotazy sú ovplyvnené)
Maximálna hodnota nadviazaných pripojení TCPV4 & Mssql používateľov závisí od nasledujúcich faktorov
a. Zložitosť vykonávacieho príkazu súvisí s tým, že čím zložitejšie je vyhlásenie, tým menší je maximálny počet spojení (tento efekt je veľmi dôležitý)
b. Súvisí to so súbežnosťou vlákien požiadavky,
10 procesov, každý proces otvorí 5 000 vlákien na požiadanie,SELECT getdate()Príkaz je už opustený, keď dosiahne približne 4000 (podľa môjho chápania, hoci mnohé vlákna nežiadali zdroje, počet požiadaviek je veľký, čo má tiež vplyv).
10 procesov, každý proces otvorí 1000 vlákien na požiadanie, SELECT getdate()Výpisy môžu dosiahnuť viac ako 10 000.
c. Súvisí s frekvenciou požiadaviek na vlákna
Ak každé vlákno vykoná dotaz a pozastaví sa na 0-10 000 milisekúnd, zaberie menej spojení, než keby nebolo pozastavené
d. V teste sa tiež zistilo, že niektoré neuzavreté spoje spôsobujú nafúknutie počítadla, čo nebolo diskutované
10 procesov, každý proces otvorí 1000 vlákien požiadaviek, náhodne sa zastaví (0 až 10 sekúnd) po každom dotaze na serveri. Výsledky testu sú nasledovné:
Realizácia:VYBRAŤ * Z [systém]. [dbo]. [DBA_alert]príkaz (tento dotaz vráti 200 riadkov a maximálny počet spojení je 700 a problém sa začne vydávať)
Keď počet pripojení dosiahne 700, začnú sa hlásiť chyby a pri 1200 sa objaví veľké množstvo chýb, pričom počet pripojení okolo 1800 sa zasekne a už nerastie. Chyby a pomalé pripojenia sú početné
Realizácia:SELECT getdate()Doba vety(Maximálny počet pripojení je 3500 a problém začína)
Keď počet pripojení dosiahne 3500, niektoré z nich začnú hlásiť chyby a najvyšší tlak dosiahne približne 11000, pričom počet pripojení stále pomaly rastie. Chyby a pomalé výpadky spojenia
Záver je: za daných tlakových podmienok: najjednoduchšie na vykonanieMaximálny počet spojení môže byť až 3500, keď SELECT getdate() a vykoná SELECT * FROM [system]. [dbo]. [DBA_alert] môže maximálny počet pripojení byť maximálne 700. Časový limit dotazu nastáva, keď CPU, IO a MEM majú veľké množstvo nevyužitých zdrojov.
V produkčnom prostredí nie je možné dosiahnuť tlak 10*1000 vlákien, ale SQL bude zložitejšie ako testovacie prostredie.
Súbežné čísloÚzke hrdlo nespôsobuje šírka pásma môjho počítača alebo serverovej siete
Aby som dokázal vyššie uvedené. Urobil som nasledujúce testy, exec dbo.run2 v prípade veľkej súbežnosti;
ALTER proc [dbo]. [beh2]
ako
Nastav nocount na
Vyberte getdate()
deklarujte @i int
Set @i=0
zatiaľ čo @i<1000 Keď je táto hodnota 1000, maximálny počet pripojení je približne 1300, a keď je táto hodnota 10, je normálne dosiahnuť 5000.
začať.
VLOŽIŤ DO [pubs]. [dbo]. [tb_test] ([name]) hodnôt (newid())
Set @i=@i+1
koniec
Choď
Počet cyklov zmien neovplyvní výsledok návratu, teda tlak na prevádzku sieťových kariet je rovnaký, ale jeden rýchlo vyprší a druhý sa dá vždy skontrolovať, takže vplyv šírky pásma sieťových kariet na oboch stranách je možné eliminovať.
Chybový obsah, keď je maximálny počet spojení zastavený:
NetStat-A výsledok, keď je maximálny počet pripojení zablokovaný (silne zavedený):
Testovací program bežiaci diagram, keď je maximálny počet pripojení zastavený:
Stojí za zmienku:Spojenie s chybami alebo časovými limitmi nie je rovnomerné a bude sústredené v niektorých procesoch, teda niektoré procesy môžu vždy bežať normálne a druhá časť bude hlásiť chyby dlhý čas (nemá to nič spoločné so štartovacím poradím procesov, podľa môjho chápania niektoré procesy majú zdroje, môžu pokračovať v normálnej práci, zatiaľ čo iné procesy vo vláknach pôvodných zdrojov sú prerušované a nemôžu žiadať o nové zdroje, budú opakovane hlásiť chyby). Ako je znázornené na obrázku vyššie, druhý a siedmy proces začali mať veľké množstvo časových limitov a ostatné procesy pokračovali v práci. Na serveri sa dotazy môžu javiť ako neovplyvnené alebo menej ovplyvnené niektorými strojmi a niektoré stroje sú výrazne ovplyvnené.
Záver: Hoci horná hranica používateľských pripojení SQLSERVER súvisí so sériou podmienok, stále je možné odhadnúť a predpovedať úzke miesto; keď sa dosiahne táto horná hranica, nastane veľké množstvo spomalených dotazov a časové limity (hoci CPU, IO). MEM, prevádzka môže vzniknúť aj vtedy, keď sú zdroje nevyužité). V skutočnosti zmena niektorých parametrov TCP zvýši tento horný limit a možno neskôr napíšem doplnky
|
Zverejnené 26. 11. 2014 15:11:08
|
|
|
|
