Maksymalna liczba połączeń użytkownika

W wersji SQL Server 2012 Standard wiem, że maksymalna liczba połączeń użytkownika wynosi 32 767. Co powinienem zrobić jako DBA, jeśli zmierzam do tego numeru?

Obecnie istnieje 30 000 połączeń użytkowników, a liczba ta prawdopodobnie wzrośnie.

Maksymalna ilość połączeń w całej wersjach SQL Server i wydaniach jest 32767.

Możesz określić, ile połączeń ma obecnie SQL Server, patrząc na:

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;

Jeśli dotyczy to stosunku między używanymi a nieużywanymi połączeniami z powyższego zapytania, prawdopodobne jest, że aplikacje klienckie podłączone do serwera są włączone do puli połączeń, a połączenia te nie są efektywnie wykorzystywane. Być może programiści powinni zmodyfikować parametry połączenia dla tych aplikacji, aby ograniczyć wielkość puli połączeń i upewnić się, że prawidłowo rozmieszczają połączenia. Jeśli połączenia nie zostaną poprawnie rozmieszczone, pozostaną otwarte tak długo, jak długo działa aplikacja kliencka.

Jeśli czujesz się szczególnie wściekłe, i trzeba pozbyć się wszystkich połączeń, które wcześniej nie wykonywanych nic niedawno (niezależnie od tego, czy są one rzeczywiście aktualnie wykonywania pracy), można uruchomić następujący kod, który wygeneruje listę sesji może zostać zabity. Będziesz musiał skopiować i wkleić wygenerowane polecenia do nowego okna SSMS, aby faktycznie je uruchomić. Na wszelki wypadek polecam również aktualizowanie CV .

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;

Możliwe jest liniowe skalowanie liczby połączeń powyżej 32 767 przez dzielenie danych na wiele węzłów programu SQL Server. Jednak moim zdaniem użycie shardingu jako sposobu na przekroczenie limitu liczby połączeń jest podobne do użycia bomby atomowej do zabicia pająka. To będzie zabić pająka, ale po prostu może mieć większe problemy na koniec dnia. Nie wspominając o tym, że zbudowanie bomby atomowej jest dość cholernie trudne, nie wspominając już o odpowiednim odłamywaniu implementacji.

W przeszłości miałem dziwne zachowanie związane z tworzeniem pul połączeń, a twój scenariusz dobrze pasuje do jednej z tych sytuacji. Jeśli twoja aplikacja korzysta z puli połączeń (i to wciąż spekulacje, dopóki tego nie potwierdzisz lub nie zaprzeczysz), będziesz mieć wiele połączeń, które pozostaną otwarte. Jest to zgodne z projektem.

Pula połączeń ma na celu zmniejszenie obciążenia związanego z tworzeniem połączenia z bazą danych. Weźmy na przykład pulę połączeń wynoszącą 3. O ile mogę stwierdzić, cykl życia przebiega mniej więcej tak (zaczynając od zimnej pamięci podręcznej puli połączeń):

1. Użytkownik aplikacji A prosi o połączenie z bazą danych
2. Pula połączeń rozpoczyna wątek 1 połączenia z bazą danych
3. Użytkownik aplikacji B prosi o połączenie z bazą danych
4. Pula połączeń rozpoczyna wątek połączenia 2 z bazą danych
5. Użytkownik aplikacji A zamyka połączenie ... z pulą połączeń
6. Użytkownik aplikacji C prosi o połączenie z bazą danych
7. Problemy z pulą połączeń sp_reset_connectionw wątku 1
8. Pula połączeń przypisuje wątek 1 użytkownikowi aplikacji C.

Jest to nadmierne uproszczenie, ale najważniejsze punkty to:

• Połączenie pozostanie otwarte między pulą wątków puli połączeń a bazą danych, dopóki baza danych lub pula połączeń nie zamknie siłą połączenia
• Połączenie pozostaje otwarte w kontekście wykonania ostatniej sesji, dopóki ten wątek nie zostanie ponownie użyty przez innego użytkownika, w którym sp_reset_connectionto momencie zostaje wywołane.

Oto materiał referencyjny, do którego doszedłem do tych wniosków.

Pula połączeń dla SQL Server DBA

Przypadek osieroconej transakcji