Максимальна кількість підключень користувачів


24

У стандартному виданні SQL Server 2012 я знаю, що максимальна кількість підключень користувачів становить 32 767. Що мені робити як DBA, якщо я пряму до цього номера?

Наразі 30 000 підключень користувачів, і очікується, що ця кількість зросте.

введіть тут опис зображення


5
Якщо вони з додатка, програма повинна закрити своє з'єднання, як тільки це закінчиться. Залишити зв’язок відкритим - можлива причина досягнення цієї межі
Марк Сінкінсон

Відповіді:


31

Максимальна кількість з'єднань в різних версіях SQL Server і видань 32767.

Ви можете визначити, скільки підключень на даний момент має SQL Server, переглянувши:

SELECT ConnectionStatus = CASE WHEN dec.most_recent_sql_handle = 0x0 
        THEN 'Unused' 
        ELSE 'Used' 
        END
    , CASE WHEN des.status = 'Sleeping' 
        THEN 'sleeping' 
        ELSE 'Not Sleeping' 
        END
    , ConnectionCount = COUNT(1)
FROM sys.dm_exec_connections dec
    INNER JOIN sys.dm_exec_sessions des ON dec.session_id = des.session_id
GROUP BY CASE WHEN des.status = 'Sleeping' 
        THEN 'sleeping' 
        ELSE 'Not Sleeping' 
        END
    , CASE WHEN dec.most_recent_sql_handle = 0x0 
        THEN 'Unused' 
        ELSE 'Used' 
        END;

Якщо співвідношення між використаними та невикористаними з'єднаннями з вищезазначеного запиту стосується, ймовірно, що об'єднання з'єднань увімкнено клієнтськими програмами, підключеними до сервера, і ці з'єднання не використовуються ефективно. Можливо, ви хочете, щоб розробники модифікували рядок з'єднання для цих додатків, щоб обмежити розмір пулу з'єднань та переконатися, що вони належним чином розміщують з'єднання. Якщо з'єднання не розміщені правильно, вони залишатимуться відкритими, поки працює клієнтська програма.

Якщо ви відчуваєте себе особливо несамовито і вам потрібно позбутися всіх з'єднань, які останнім часом нічого не виконували (незалежно від того, чи справді вони зараз виконують роботу), ви можете запустити наступний код, який створить список сеансів, які можна вбити. Вам потрібно буде скопіювати та вставити згенеровані команди у нове вікно SSMS, щоб фактично запустити команди. Я також рекомендую оновлювати своє резюме на всякий випадок .

DECLARE @cmd NVARCHAR(MAX);
SET @cmd = '';
SELECT @cmd = @cmd + 
    CASE WHEN @cmd = '' THEN '' ELSE CHAR(13) + CHAR(10) END 
    + 'KILL ' + CONVERT(VARCHAR(MAX), dec.session_id) + ';'
FROM sys.dm_exec_connections dec
WHERE dec.most_recent_sql_handle = 0x0;

PRINT @cmd;

Можна лінійно масштабувати кількість з'єднань, що перевищують 32 767, зменшуючи дані по декількох вузлах SQL Server. Однак, на мій погляд, використання шардингу як способу подолати обмеження кількості з'єднань аналогічно використанню атомної бомби для вбивства павука. Він буде вбивати павука, але ви просто могли б мати великі проблеми в кінці дня. Не кажучи вже про те, що скласти атомну бомбу досить важко, не кажучи вже про належне реагування на шар.


1
Чи можете ви пояснити, чому нам слід ідентифікувати "вбивчі" сеанси , використовуючи most_recent_sql_handle у з'єднаннях sys.dm_exec_, а не використовуючи, скажімо, статус та last_request_start_time та is_user_process в сесіях sys.dm_exec_ ? Це здається дивним вибором.
Майк Шеррілл 'Відкликання котів'

Це хороший момент, @Mike - У той час я думав виключно про з'єднання, які були відкриті об'єднанням з'єднань і які ніколи не використовувалися. Було б хорошою ідеєю додати в is_user_processкваліфікатор, і, звичайно, не завадить виключити сеанси, які мають last_request_start_timeдещо останній час. Як недавно? Ще одне хороше запитання.
Макс Вернон

Можливо, last_request_start_time повинен бути старшим, ніж новішим. Я думаю, що безпечне "вбивче" користувацьке сеанс було б тим, хто спить, і не було запиту вже пару днів. Я думаю, що час відключення залежить від того, наскільки добре наші програмісти прикладних програм прибирають після себе.
Майк Шеррілл 'Згадка про котів'

12

У минулому я стикався з дивною поведінкою при об'єднанні з'єднань, і ваш сценарій добре узгоджується з однією з таких ситуацій. Якщо у вашій програмі використовується об'єднання з'єднань (і це все ще міркування, до цього моменту, поки ви не підтвердите або не заперечите це), у вас буде багато з’єднань, які залишаються відкритими. Це за дизайном.

Об'єднання об'єднань має на меті зменшити накладні витрати на створення з'єднання з базою даних. Візьмемо, наприклад, пул підключень 3. Наскільки я можу сказати, життєвий цикл проходить приблизно так (починаючи з холодного кеша пулу з'єднань):

  1. Користувач програми A запитує про з'єднання з базою даних
  2. Пул з'єднань починає потік з'єднання 1 до бази даних
  3. Користувач програми B запитує про з'єднання з базою даних
  4. Пул з'єднань починає потік з'єднання 2 до бази даних
  5. Користувач програми A закриває своє з'єднання ... до пулу з'єднань
  6. Користувач програми C просить підключитися до бази даних
  7. Випуски пулу підключень sp_reset_connectionна потоці 1
  8. Пул підключень призначає потік 1 користувачеві програми C

Це надмірне спрощення, але важливі моменти включають:

  • З'єднання залишатиметься відкритим між пулом потоків пулу з'єднання та базою даних до тих пір, поки база даних або пул з'єднання насильно не закриють з'єднання
  • З'єднання залишається відкритим з контекстом виконання останніх сеансів, поки цей потік не буде використаний повторно іншим користувачем, в який момент часу sp_reset_connectionвикликається.

Ось довідковий матеріал, який я використовував, щоб дійти до цих висновків.

Пул з'єднання для DBA SQL Server

Справа сирітської угоди

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.