|
Зв'язки користувачів SQLSERVER Загальна статистика User Connections екземпляра SQL у лічильнику продуктивності відповідає їй Ви також можете звернутися до TCPv4Connections Established у лічильнику продуктивності
На машині з лише сервісом 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] ([ім'я]) значення (newid())
множина @i=@i+1
кінець
Іди
Кількість циклів змін не впливає на результат повернення, тобто тиск на трафік мережевої карти однаковий, але один швидко закінчується, а інший завжди можна перевірити, тож вплив пропускної здатності мережевих карт з обох сторін можна усунути.
Вміст помилки при зупинці максимальної кількості з'єднань:
NetStat — результат, коли максимальна кількість з'єднань застрягла (сильно встановлено):
Тестова програма, що виконує діаграму, коли максимальна кількість з'єднань зупиняється:
Варто зазначити:Зв'язок із помилками або тайм-аутами не є рівним і буде зосереджений у деяких процесах, тобто деякі процеси завжди можуть працювати нормально, а інша частина довго повідомлятиме про помилки (це не пов'язано з порядком початку процесів, наскільки я розумію, деякі процеси мають ресурси, можуть продовжувати працювати нормально, тоді як інші процеси в потоках оригінальних ресурсів випереджені і не можуть подавати заявку на нові ресурси, вони постійно повідомлятимуть про помилки). Як показано на рисунку вище, 2-й і 7-й процеси почали мати велику кількість тайм-аутів, а інші процеси продовжували працювати. На сервері запити можуть виглядати як незмінні або менш зазнали впливу деяких машин, а деякі машини зазнають суттєвих змін.
Висновок: Хоча верхня межа користувацьких з'єднань SQLSERVER пов'язана з низкою умов, все ж можливо оцінити та передбачити вузьке місце; коли досягнуто цього верхнього межу, буде багато запитів уповільнення та тайм-аутів (хоча CPU, IO). MEM, трафік також може виникати, коли є ресурси простою). Насправді, зміна деяких параметрів TCP збільшить цей верхній ліміт, і, можливо, я напишу додаткові матеріали пізніше
|
Опубліковано 26.11.2014 15:11:08
|
|
|
|
