Maksymalna liczba połączeń

Maksymalna liczba połączeń to ustawienie SQL Server ograniczające liczbę jednoczesnych sesji klientów.

Co oznacza maksymalna liczba połączeń w SQL Server

Maksymalna liczba połączeń w SQL Server jest wartością konfiguracyjną określającą limit jednoczesnych połączeń użytkowników z instancją silnika bazy danych. Połączenie może pochodzić między innymi z aplikacji, narzędzia administracyjnego, usługi systemowej albo skryptu wykorzystującego sterownik SQL Server. Limit dotyczy całej instancji, a nie pojedynczej bazy danych znajdującej się na tej instancji. Wszystkie aktywne i utrzymywane przez klienta sesje konkurują więc o wspólną pulę dopuszczonych połączeń.

W SQL Server ustawienie nosi nazwę user connections. Jego wartość domyślna wynosi 0, co oznacza automatyczny dobór maksymalnej liczby połączeń przez silnik na podstawie dostępnych zasobów. SQL Server może obsługiwać do 32 767 połączeń użytkowników, ale osiągnięcie takiej liczby nie jest gwarantowane ani zwykle pożądane. Rzeczywista zdolność obsługi zależy między innymi od pamięci RAM, liczby procesorów, konfiguracji puli wątków, obciążenia zapytań oraz sposobu działania aplikacji klienckich.

Sprawdzanie wartości i konfiguracja parametru

Bieżącą konfigurację można sprawdzić w SQL Server Management Studio albo w innym kliencie T-SQL. Przykładowe zapytanie odczytuje wartość skonfigurowaną oraz wartość używaną przez uruchomiony silnik:

SELECT name, value, value_in_use, description FROM sys.configurations WHERE name = 'user connections';

Wartość value jest wartością zapisaną w konfiguracji, natomiast value_in_use pokazuje ustawienie aktualnie stosowane przez instancję. Przydatna jest także funkcja @@MAX_CONNECTIONS, która zwraca maksymalną liczbę jednoczesnych połączeń dopuszczoną przez bieżącą instancję. Przykład odczytu wygląda następująco: SELECT @@MAX_CONNECTIONS AS max_connections;. Wynik należy interpretować razem z informacjami o obciążeniu serwera, ponieważ sam limit nie określa, ile sesji będzie działało sprawnie.

Zmiana limitu a zachowanie aplikacji

Parametr można zmienić procedurą systemową sp_configure. Najpierw należy włączyć możliwość wyświetlania zaawansowanych opcji, następnie ustawić wartość parametru i zatwierdzić konfigurację:

EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'user connections', 200; RECONFIGURE;

Podana liczba jest przykładowa i nie powinna być kopiowana bez analizy środowiska. Ustawienie zbyt niskiego limitu może powodować odrzucanie nowych prób logowania, gdy wszystkie dostępne miejsca zostaną zajęte. Aplikacja może wtedy zgłaszać błędy otwierania sesji, przekroczenia czasu oczekiwania albo brak dostępnych połączeń w puli. Zbyt wysoka wartość również nie rozwiązuje problemu nieefektywnego kodu. Każde połączenie zużywa zasoby serwera, a wiele aktywnych zapytań może prowadzić do presji pamięci, oczekiwania na wątki, blokad i wydłużenia czasu odpowiedzi.

W praktyce aplikacje powinny korzystać z puli połączeń, zamykać lub zwalniać obiekty po zakończeniu pracy i unikać tworzenia nowej sesji dla każdej pojedynczej operacji, jeżeli używany sterownik obsługuje ponowne wykorzystanie połączeń. Przy diagnozowaniu problemu warto rozróżnić połączenia faktycznie wykonujące zapytania od sesji bezczynnych, które pozostają otwarte przez błędną obsługę puli albo nieprawidłowe zarządzanie cyklem życia klienta. Zwiększenie limitu ma sens dopiero po ustaleniu, czy ograniczeniem jest rzeczywiście liczba połączeń, a nie blokady, wolne zapytania, brak zasobów lub awaria aplikacji.

Diagnostyka przekroczenia liczby połączeń

Jeżeli SQL Server odrzuca nowe sesje, należy sprawdzić liczbę istniejących połączeń oraz ich stan. Informacje o sesjach można analizować przez widoki dynamicznego zarządzania, na przykład sys.dm_exec_sessions i sys.dm_exec_connections. Proste zestawienie liczby sesji według statusu przygotowuje zapytanie:

SELECT status, COUNT(*) AS session_count FROM sys.dm_exec_sessions GROUP BY status;

Do pełnej analizy potrzebne są także dane o użytkowniku, aplikacji, hoście, czasie ostatniego żądania i aktualnie wykonywanym poleceniu. Powtarzające się sesje bezczynne z tego samego programu mogą wskazywać na niewłaściwe ustawienie puli połączeń. Z kolei wiele sesji aktywnych jednocześnie może być prawidłowym skutkiem pracy aplikacji, ale wymaga oceny zapytań i czasu ich wykonywania. Samo zabijanie sesji poleceniem KILL usuwa objaw tylko doraźnie i może przerwać transakcje, dlatego przed takim działaniem trzeba ustalić właściciela sesji oraz możliwe skutki dla aplikacji.

Przed zmianą konfiguracji należy wykonać kopię bieżących ustawień, sprawdzić uprawnienia administracyjne i zaplanować obserwację po zmianie. Warto porównać liczbę połączeń z licznikami wydajności, logami aplikacji oraz czasem odpowiedzi zapytań. Jeżeli problem pojawia się po restarcie usługi, wdrożeniu nowej wersji programu albo zmianie konfiguracji puli, przyczyna może znajdować się poza samym parametrem SQL Server. Diagnostyka powinna więc obejmować cały przepływ: otwarcie sesji przez klienta, uwierzytelnienie, wykorzystanie połączenia, zwolnienie go do puli i ponowne użycie.