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