|
SQLSERVER потребителски връзки Общата статистика Потребителските връзки на SQL екземпляра в брояча на производителността съответстват на нея Можете също да се обърнете към TCPv4Connections Established в брояча на производителността
На машина само с услугата SQLSERVER,Установени връзки с TCPV4 и MSSQL UserConnectionsТези два параметъра са по същество синхронизирани и се наричат броят на връзките в следващото тестово съдържание
Този брой връзки е ограничен, подобно на максималния брой лимити за съвместно движение. Когато този лимит бъде достигнат, заявките ще станат неотзивчиви, дори ако има свободни CPU, IO и MEM ресурси (някои, не всички заявки са засегнати)
Максималната стойност на TCPV4 Connections Established и Mssql UserConnections зависи от следните фактори
a. Сложността на изказването за изпълнение е свързана – колкото по-сложно е изразяването, толкова по-малък е максималният брой връзки (този ефект е много важен)
b. Свързано е с конкурентността на нишката на заявката,
10 процеса, всеки процес отваря 5 000 нишки за заявка,ИЗБЕРЕТЕ getdate()Твърдението вече е изоставено, когато достигне около 4000 (доколкото знам, въпреки че много нишки не са поискали ресурси, броят на заявките е голям, което също има влияние).
10 процеса, всеки процес отваря 1000 нишки за заявка, ИЗБЕРЕТЕ getdate()Извлеченията могат да достигнат повече от 10 000.
в. Свързано е с честотата на заявките за нишки
Ако всяка нишка изпълни заявка и паузира за 0-10 000 милисекунди, тя ще заеме по-малко връзки, отколкото ако не е спряна
г. В теста беше установено, че някои незатворени връзки водят до надуване на брояча, което не беше обсъждано
10 процеса, всеки процес отваря 1000 нишки за заявки, паузира на случаен принцип (0 до 10 секунди) след всяка заявка на сървъра. Резултатите от теста са следните:
Изпълнение:ИЗБЕРЕТЕ * ОТ [система]. [DBO]. [DBA_alert]твърдение (тази заявка връща 200 реда, а максималният брой връзки е 700 и проблемът започва да се издава)
Когато броят на връзките достигне 700, започват да се докладват някои грешки, а при 1200 започват да се появяват голям брой грешки, като броят на връзките около 1800 остава блокиран и вече не се увеличава. Грешки и бавни връзки са изобилни
Изпълнение:ИЗБЕРЕТЕ getdate()Време на присъдата(Максималният брой връзки е 3500 и проблемът започва)
Когато броят на връзките достигне 3500, някои от тях започват да докладват грешки, а най-високото налягане достига около 11000, а броят на връзките продължава бавно да расте. Грешки и бавни прекъсвания на връзката
Заключението е: при дадени условия на налягане: най-лесният за изпълнениеМаксималният брой връзки може да достигне до 3500 при SELECT getdate(), и при изпълнение на SELECT * ОТ [система]. [DBO]. [DBA_alert] оператор, максималният брой връзки може да бъде само до 700. Таймаут на заявката настъпва, когато CPU, IO и MEM имат голям брой неактивни ресурси.
В продукционната среда напрежението от 10*1000 нишки не може да бъде достигнато, но SQL ще бъде по-сложен от тестовата среда.
Съвременен номерТесното място не е причинено от пропускателната способност на компютъра ми или сървърната мрежова карта
За да докажа горното. Направих следните тестове, exec dbo.run2 при голяма паралелност;
ALTER proc [dbo]. [бягане 2]
като
Задайте nocount на
Изберете getDate()
Декларирам @i int
set @i=0
докато @i<1000 Когато тази стойност е 1000, максималният брой връзки е около 1300, а когато тази стойност е 10, нормално се достига 5000.
Начало
ВМЪКНЕТЕ В [публикации]. [DBO]. [tb_test] ([име]) стойности (newid())
set @i=@i+1
край
Върви
Броят на циклите на промяна няма да повлияе на резултата от връщането, тоест натискът върху трафика на мрежовата карта е същият, но единият ще изтече бързо и другият винаги може да бъде проверен, така че въздействието на пропускателната способност на мрежовите карти от двете страни може да бъде елиминирано.
Съдържание на грешка, когато максималният брой връзки е блокиран:
NetStat – резултат, когато максималният брой връзки е блокиран (силно установен):
Тестова програма, която изпълнява диаграма, когато максималният брой връзки е спрян:
Струва си да се отбележи:Връзката с грешки или таймаути не е равномерна и ще бъде концентрирана в някои процеси, тоест някои процеси винаги могат да работят нормално, а другата част ще докладва грешки за дълго време (няма нищо общо с началния ред на процесите, доколкото знам, някои процеси имат ресурси, могат да продължат да работят нормално, докато други процеси в нишките в оригиналните ресурси са прекратени и не могат да кандидатстват за нови ресурси, ще продължат да докладват грешки многократно). Както е показано на горната фигура, вторият и седмият процес започнаха да имат голям брой таймаути, а други процеси продължиха да работят. На сървъра заявките може да изглеждат незасегнати или по-малко засегнати от някои машини, а някои машини са значително засегнати.
Заключение: Въпреки че горната граница на SQLSERVER User Connections е свързана с поредица от условия, все пак е възможно да се оцени и предвиди тесното място; когато тази горна граница бъде достигната, ще има голям брой забавени заявки и таймаути (въпреки CPU, IO). MEM, трафикът може да възникне и когато има неактивни ресурси). Всъщност, промяната на някои параметри на TCP ще увеличи тази горна граница и може би по-късно ще напиша допълнителни материали
|
Публикувано в 26.11.2014 г. 15:11:08 ч.
|
|
|
|
