|
Uživatelská připojení SQLSERVER Obecné statistikyUživatelská spojení SQL instance v výkonnostním čítači mu odpovídají Můžete také odkazovat na TCPv4Connections Established v ukazateli výkonu
Na stroji, kde je pouze služba SQLSERVER,TCPV4 spojení navázaná & Mssql uživatelská připojeníTyto dva parametry jsou v podstatě synchronizované a v následujícím testovacím obsahu se označují jako počet spojení
Tento počet spojení je omezený, podobně jako maximální počet limitů souběžnosti. Když je tento limit dosažen, dotazy se stanou neodpovídajícími i v případě, že jsou k dispozici volné CPU, IO a MEM zdroje (některé, ne všechny dotazy jsou ovlivněny)
Maximální hodnota TCPV4 Connection Established & Mssql UserConnections závisí na následujících faktorech
a. Složitost příkazu vykonání souvisí s tím, že čím složitější je příkaz, tím menší je maximální počet spojení (tento efekt je velmi důležitý)
b. Souvisí s konkurenčním řetězcem žádosti,
10 procesů, každý proces otevírá 5 000 vláken k požadavku,SELECT getdate()Prohlášení je již opuštěno, když dosáhne přibližně 4000 (podle mého chápání i když mnoho vláken nežádalo o zdroje, počet žádostí je velký, což má také dopad).
10 procesů, každý proces otevírá 1000 vláken k požadavku, SELECT getdate()Výpisy mohou dosáhnout více než 10 000.
c. Souvisí s frekvencí požadavků na vlákna
Pokud každé vlákno provede dotaz a pozastaví se na 0–10 000 milisekund, zabere méně spojení než kdyby nebylo pozastaveno
d. V testu bylo také zjištěno, že některé neuzavřené spoje způsobí nafouknutí počítadla, což nebylo diskutováno
10 procesů, každý proces otevře 1000 vláken požadavků, náhodně se pozastaví (0 až 10 sekund) po každém dotazu na serveru. Výsledky testu jsou následující:
Realizace:VYBERTE * Z [systém]. [dbo]. [DBA_alert](tento dotaz vrací 200 řádků a maximální počet spojení je 700 a problém začíná být vydáván)
Když počet připojení dosáhne 700, začnou se hlásit chyby a při 1200 se objevuje velké množství chyb a počet spojení kolem 1800 zůstává zaseknutý a už neroste. Chyby a pomalé připojení jsou hojné
Realizace:SELECT getdate()Doba věty(Maximální počet spojení je 3500 a problém začíná )
Když počet připojení dosáhne 3500, některá z nich začnou hlásit chyby a nejvyšší tlak dosahuje kolem 11000, přičemž počet připojení stále pomalu roste. Chyby a pomalé výpadky spojení
Závěr je: za daných tlakových podmínek: nejjednodušší k provedeníMaximální počet spojení může být až 3500 při SELECT getdate() a vykonání SELECT * FROM [system]. [dbo]. [DBA_alert] může maximální počet připojení být maximálně 700. Časový limit dotazu nastává, když mají CPU, IO a MEM velké množství nečinných zdrojů.
V produkčním prostředí nelze dosáhnout tlaku 10*1000 vláken, ale SQL bude složitější než testovací prostředí.
Souběžné čísloÚzké hrdlo není způsobeno šířkou pásma mého počítače nebo serverové karty
Abych dokázal výše uvedené. Provedl jsem následující testy, exec dbo.run2 v případě velké souběžnosti;
ALTER proc [dbo]. [běh 2]
jako
Nastavte nocount na
Vyberte getdate()
deklarujte @i int
Set @i=0
zatímco @i<1000 Když je tato hodnota 1000, maximální počet spojení je asi 1300, a pokud je tato hodnota 10, je normální dosáhnout 5000.
začátek
VLOŽTE DO [pubs]. [dbo]. [tb_test] ([názvy]) hodnoty (newid())
množina @i=@i+1
konec
Jdi
Počet cyklů změn neovlivní výsledek návratu, tedy tlak na provoz síťové karty je stejný, ale jeden rychle vyprší a druhý lze vždy zkontrolovat, takže lze eliminovat dopad šířky pásma síťových karet na obou stranách.
Chybový obsah, když je maximální počet spojení zastaven:
NetStat-Výsledek při maximálním počtu spojení (silně zavedené):
Testovací schéma běžícího programu, když je maximální počet spojení zastaven:
Stojí za zmínku:Spojení s chybami nebo timeouty není rovnoměrné a bude soustředěno v některých procesech, tedy některé procesy mohou vždy běžet normálně, zatímco druhá část bude hlásit chyby dlouho (nemá to nic společného se startovním pořadím procesů, podle mého chápání některé procesy mají zdroje, mohou pokračovat v normálním provozu, zatímco jiné procesy ve vláknech původních zdrojů jsou přerušeny a nemohou aplikovat na nové zdroje, budou opakovaně hlásit chyby). Jak je ukázáno na obrázku výše, druhý a sedmý proces začaly mít velké množství timeoutů a ostatní procesy pokračovaly v práci. Na serveru se dotazy mohou jevit jako neovlivněné nebo méně ovlivněné některými stroji, zatímco některé stroje jsou výrazně ovlivněny.
Závěr: Ačkoli horní hranice uživatelských připojení SQLSERVER souvisí s řadou podmínek, stále je možné odhadnout a předpovědět úzké hrdlo; když je dosaženo této horní hranice, dojde k velkému počtu pomalých dotazů a časových limitů (i když CPU, IO). MEM provoz může nastat i tehdy, když jsou nevyužité zdroje). Ve skutečnosti změna některých parametrů TCP zvýší tento horní limit a možná později napíšu doplňky
|
Zveřejněno 26.11.2014 15:11:08
|
|
|
|
