Podczas korzystania ze sterownika ODBC lub dostawcy OLE DB dla programu SQL Server albo zarządzanego dostawcy System.Data.SqlClient można wyłączyć buforowanie połączeń przy użyciu poszczególnych interfejsów programowania aplikacji (API, Application Programming Interface). Jeśli aplikacja często otwiera i zamyka połączenia, po wyłączeniu buforowania może zwiększyć się obciążenie podstawowej biblioteki sieciowej programu SQL Server. W tym artykule opisano pewne ustawienia TCP/IP, które w takiej sytuacji należy dostosować.
Streszczenie
Wyłączenie buforowania może spowodować, że podstawowy sterownik sieci programu SQL Server będzie otwierał i natychmiast zamykał nowe połączenia z gniazdem komputera, na którym uruchomiono program SQL Server. Być może do obsłużenia wyższych poziomów obciążenia będzie niezbędna zmiana domyślnych ustawień gniazd TCP/IP w systemie operacyjnym i na komputerze, na którym uruchomiono program SQL Server.
Należy pamiętać, że w tym artykule omówiono tylko ustawienia dotyczące biblioteki sieciowej programu SQL Server podczas korzystania z protokołu TCP/IP. Wyłączenie buforowania może spowodować problemy związane z przeciążeniem dotyczące również innych protokołów programu SQL Server, takich jak potoki nazwane, ale nie stanowią one tematu tego artykułu. Ten artykuł jest przeznaczony tylko dla użytkowników zaawansowanych. Jeśli tematy tego artykułu są niezrozumiałe, firma Microsoft zaleca przeczytanie dobrej książki o gniazdach TCP/IP.
Należy zwrócić uwagę, że firma Microsoft zdecydowanie zaleca, aby ze sterownikami programu SQL Sever zawsze używać funkcji buforowania. Użycie buforowania sterowników programu SQL Server w znaczący sposób zwiększa ogólną wydajność zarówno po stronie klienta, jak i po stronie programu SQL Server. Buforowanie znacząco zmniejsza również ruch sieciowy w kierunku komputera, na którym uruchomiono program SQL Server. Na przykład w przeprowadzonym teście na 20 000 otwarć i zamknięć połączenia programu SQL Server z włączonym buforowaniem użyto około 160 pakietów sieciowych TCP/IP, czyli 23 520 bajtów całkowitej aktywności sieci. Po wyłączeniu buforowania w tym samym teście wygenerowano 225 129 pakietów sieciowych TCP/IP, czyli 27 209 622 bajtów całkowitej aktywności sieciowej.
Przeglądając listę tych problemów związanych z obciążeniem gniazd TCP/IP z bibliotekami sieciowymi programu SQL Server, należy pamiętać, że przy próbie połączenia się z komputerem, na którym uruchomiono program SQL Server, może się pojawić jeden lub kilka następujących komunikatów o błędzie:
Serwer SQL nie istnieje lub odmówiono do niego dostępu
Upłynął limit czasu
Błąd ogólny sieci
Należy pamiętać, że te specyficzne komunikaty o błędzie mogą się pojawić również po wystąpieniu innych problemów z programem SQL Server; na przykład te komunikaty o błędzie mogą się pojawić wtedy, gdy komputer zdalny, na którym uruchomiono program SQL Server, został zamknięty; komputer zdalny, na którym uruchomiono program SQL Server, w ogóle nie nasłuchuje za pomocą gniazd TCP/IP; połączenie sieciowe z komputerem, na którym uruchomiono program SQL Server, zostało zerwane z powodu wyciągnięcia wtyczki kabla sieciowego; lub występują problemy z rozpoznawaniem nazw DNS. Zasadniczo wszystko, co może spowodować, że klient nie będzie mógł otworzyć gniazda TCP/IP na komputerze, na którym uruchomiono program SQL Server, może również stanowić przyczynę komunikatów o błędach. Jednak problem dotyczący gniazda związanego z obciążeniem występuje czasowo podczas wzrostów i spadków obciążenia. Komputer może działać godzinami bezbłędnie, następnie błąd może wystąpić raz lub dwa razy, po czym komputer będzie dalej działał kilka godzin bezbłędnie. Po wystąpieniu tego problemu ogólna łączność z programem SQL Server jest w jednej chwili poprawna, w drugiej nie, a w kolejnej znowu poprawna. Innymi słowy problemy dotyczące gniazda związanego z obciążeniem występują zwykle sporadycznie, natomiast rzeczywiste problemy dotyczące połączenia sieciowego z programem SQL Server zwykle nie występują sporadycznie.
Po wyłączeniu buforowania podczas korzystania z protokołu TCP/IP w programie SQL Server występują zwykle dwa główne problemy związane z obciążeniem: wyczerpanie się portów anonimowych na komputerze klienckim lub przekroczenie wartości domyślnego ustawienia WinsockListenBacklog na komputerze, na którym uruchomiono program SQL Server.
Aby uzyskać dodatkowe informacje dotyczące portów anonimowych, kliknij numer artykułu poniżej w celu wyświetlenia tego artykułu z bazy wiedzy Microsoft Knowledge Base:
319502 PRB: 'WSAEADDRESSINUSE' Error Message When You Try to Connect Through an Anonymous Port After You Increase the IMAP Connection Limit
Dopasowywanie ustawień MaxUserPort i TcpTimedWaitDelay
Należy pamiętać, że ustawienia MaxUserPort i TcpTimedWaitDelay mają zastosowanie tylko do komputera klienckiego, który otwiera i natychmiastowo zamyka połączenia z komputerem zdalnym, na którym uruchomiono program SQL Server i który nie korzysta z buforowania połączeń. Na przykład ustawienia te mają zastosowanie do serwera Internetowych usług informacyjnych (IIS, Internet Information Services), który obsługuje dużą liczbę przychodzących żądań HTTP oraz otwiera i zamyka połączenia z komputerem zdalnym, na którym uruchomiono program SQL Server i który korzysta z protokołu TCP/IP z wyłączoną funkcją buforowania. Po włączeniu buforowania nie trzeba dopasowywać ustawień MaxUserPort i TcpTimedWaitDelay.
Po użyciu protokołu TCP/IP do otwarcia połączenia z komputerem, na którym uruchomiono program SQL Server, podstawowa biblioteka sieciowa programu SQL Server otworzy gniazdo TCP/IP na tym komputerze. Po otwarciu tego gniazda biblioteka sieciowa programu SQL Server nie włączy opcji gniazda TCP/IP SO_REUSEADDR. Więcej informacji dotyczących ustawienia gniazda SO_REUSEADDR można znaleźć w temacie „Setsockopt” w usłudze MSDN (Microsoft Developer Network).
Należy zwrócić uwagę, że biblioteka sieciowa programu SQL Server nie włącza opcji gniazda TCP/IP SO_REUSEADDR ze względów bezpieczeństwa. Po włączeniu opcji SO_REUSEADDR złośliwy użytkownik może przejąć port klienta do programu SQL Server i użyć poświadczeń dostarczonych przez klienta w celu uzyskania dostępu do komputera, na którym uruchomiono program SQL Server. Domyślnie, ponieważ biblioteka sieciowa programu SQL Server nie włącza opcji gniazda SO_REUSEADDR, przy każdym otwarciu i zamknięciu gniazda za pomocą biblioteki sieciowej programu SQL Server po stronie klienta gniazdo przechodzi na cztery minuty w stan CZAS_OCZEKIWANIA. Błyskawiczne otwieranie i zamykanie połączeń programu SQL Server przy użyciu protokołu TCP/IP z wyłączoną funkcją buforowania oznacza błyskawiczne otwieranie i zamykanie gniazd TCP/IP. Innymi słowy każdemu połączeniu programu SQL Server odpowiada jedno gniazdo TCP/IP. Jeśli w czasie krótszym niż cztery minuty zostanie błyskawicznie otwartych i zamkniętych 4000 gniazd, nastąpi przekroczenie domyślnej maksymalnej wartości ustawienia dotyczącego klienckich portów anonimowych i próba połączenia się z nowym gniazdem będzie kończyć się niepowodzeniem, dopóki nie upłynie limit czasu CZAS_OCZEKIWANIA istniejącego zestawu gniazd.
Jeśli wyłączono buforowanie, po stronie klienta konieczne może się okazać zwiększenie wartości ustawień MaxUserPort i TcpTimedWaitDelay, które omówiono w artykule Q319502. Wartości tych ustawień odpowiadają liczbie otwartych i zamkniętych połączeń programu SQL Server po stronie klienta. Za pomocą narzędzia Netstat na komputerze klienckim można określić liczbę portów klienckich znajdujących się w stanie CZAS_OCZEKIWANIA. Narzędzie Netstat należy uruchomić z przełącznikiem -n zgodnie z instrukcją i policzyć liczbę gniazd klienckich z adresem IP programu SQL Server, które znajdują się w stanie CZAS_OCZEKIWANIA. W tym przykładzie adresem IP komputera zdalnego, na którym uruchomiono program SQL Server, jest ciąg 10.10.10.20; adresem IP komputera klienckiego jest ciąg 10.10.10.10; ustanowiono trzy połączenia, z których dwa znajdują się w stanie CZAS_OCZEKIWANIA:
C:\>netstat -n
Aktywne połączenia
Protokół Adres lokalny Obcy adres Stan
TCP 10.10.10.10:2000 10.10.10.20:1433 USTANOWIONO
TCP 10.10.10.10:2001 10.10.10.20:1433 USTANOWIONO
TCP 10.10.10.10:2002 10.10.10.20:1433 USTANOWIONO
TCP 10.10.10.10:2003 10.10.10.20:1433 CZAS_OCZEKIWANIA
TCP 10.10.10.10:2004 10.10.10.20:1433 CZAS_OCZEKIWANIA
Jeśli uruchomiono polecenie netstat -n i widać, że prawie 4000 połączeń z adresem IP komputera docelowego, na którym uruchomiono program SQL Server, znajduje się w stanie CZAS_OCZEKIWANIA, można zarówno zwiększyć domyślną wartość ustawienia MaxUserPort, jak i zmniejszyć wartość ustawienia TcpTimedWaitDelay, dzięki czemu pula klienckich portów anonimowych nie wyczerpie się. Na przykład można ustawić wartość MaxUserPort na 20 000 i wartość TcpTimedWaitDelay na 30. Niższa wartość ustawienia TcpTimedWaitDelay skraca czas oczekiwania gniazd w stanie CZAS_OCZEKIWANIA. Wyższa wartość ustawienia MaxUserPort zwiększa maksymalną liczbę gniazd, które mogą być w stanie CZAS_OCZEKIWANIA.
Należy pamiętać, że po dopasowaniu ustawienia MaxUserPort lub TcpTimedWaitDelay trzeba ponownie uruchomić system Microsoft Windows, aby nowe ustawienie zostało uwzględnione. Wartości ustawień MaxUserPort i TcpTimedWaitDelay dotyczą każdego komputera klienckiego komunikującego się z komputerem, na którym uruchomiono program SQL Server, za pomocą gniazd TCP/IP. Ustawienia te nie zostaną uwzględnione, jeśli skonfigurowano je na komputerze, na którym uruchomiono program SQL Server, chyba że dotyczą połączeń z lokalnymi gniazdami TCP/IP utworzonych na komputerze lokalnym, na którym uruchomiono program SQL Server.
Dopasowywanie ustawienia WinsockListenBacklog
Aby uzyskać dodatkowe informacje o tym specyficznym ustawieniu rejestru dotyczącym programu SQL Server, kliknij numer artykułu poniżej w celu wyświetlenia tego artykułu z bazy wiedzy Microsoft Knowledge Base:
154628 INF: SQL Logs 17832 with Multiple TCP\IP Connection Requests
Domyślną wartością ustawienia programu SQL Server WinsockListenBacklog jest 5. Oznacza ona, że komputer, na którym uruchomiono program SQL Server, przekazuje wartość 5 do parametru zaległości interfejsu Winsock API, oczekującego na sygnał po skonfigurowaniu wątków nasłuchiwania protokołu TCP/IP na komputerze, na którym uruchomiono program SQL Server. Ustawienie zaległości określa maksymalną długość kolejki połączeń oczekujących na nasłuchującego. Po przekroczeniu długości tej kolejki dodatkowe próby połączeń z gniazdem TCP/IP na komputerze, na którym uruchomiono program SQL Server, będą natychmiast odrzucane za pomocą pakietu ACK+RESET.
Ustawienie zaległości ma następujące działanie: przypuśćmy, że dowolna usługa nasłuchuje przychodzących żądań dotyczących gniazda TCP/IP. Jeśli wartość parametru zaległości ustawiono na 5, a w sposób ciagły napływa wiele żądań połączenia z gniazdem, usługa może nie być w stanie odpowiadać na żądania przychodzące równie szybko, jak one napływają. W takiej sytuacji warstwa gniazd TCP/IP umieszcza żądania przychodzące w kolejce zaległości, dzięki czemu usługa może później wyprowadzić je z tej kolejki i obsłużyć przychodzące żądanie połączenia z gniazdem. Po zapełnieniu kolejki warstwa gniazd TCP/IP natychmiast odrzuci wszelkie dodatkowe żądania przychodzące, odsyłając pakiet ACK+RESET do klienta. Zwiększanie długości kolejki zaległości zwiększa liczbę oczekujących żądań połączenia z gniazdem, które warstwa gniazd TCP/IP umieści w kolejce, zanim odrzuci żądania.
Należy pamiętać, że ustawienie WinsockListenBacklog jest specyficzne dla programu SQL Server. Program SQL Server próbuje odczytać wartość tego ustawienia rejestru przy pierwszym uruchomieniu usługi SQL Server. Jeśli ustawienie nie istnieje, zostanie użyta wartość domyślna 5. Jeśli ustawienie istnieje, program SQL Server odczyta jego wartość i użyje jej jako ustawienia zaległości po wywołaniu nasłuchującego interfejsu WinSock API, zgodnie z konfiguracją wątków nasłuchiwania gniazda TCP/IP wewnątrz programu SQL Server.
Aby ustalić, czy ten problem wystąpi, należy uruchomić śledzenie Monitora sieci na komputerze, na którym uruchomiono program SQL Server, i wyszukać żądania połączenia z gniazdem, które zostały natychmiast odrzucone za pomocą pakietu ACK+RESET. Po zbadaniu pakietów TCP/IP w Monitorze sieci można zauważyć pakiet podobny do następującego, który oznacza wystąpienie tego problemu:
Frame: Base frame properties
ETHERNET: EType = Internet IP (IPv4)
IP: Protocol = TCP - Transmission Control; Packet ID = 40530; Total IP Length = 40; Options = No Options
TCP: Control Bits: .A.R.., len: 0, seq: 0-0, ack:3409265780, win: 0, src: 1433 dst: 4364
TCP: Source Port = 0x0599
TCP: Destination Port = 0x110C
TCP: Sequence Number = 0 (0x0)
TCP: Acknowledgement Number = 3409265780 (0xCB354474)
TCP: Data Offset = 20 bytes
TCP: Flags = 0x14 : .A.R..
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....1.. = Reset the connection
TCP: ......0. = No Synchronize
TCP: .......0 = Not the end of the data
TCP: Window = 0 (0x0)
TCP: Checksum = 0xF1E7
TCP: Urgent Pointer = 0 (0x0)
Należy zwrócić uwagę, że portem źródłowym jest port 0x599 (lub 1433 dziesiętnie). Oznacza to, że pakiet pochodzi z typowego komputera, na którym uruchomiono program SQL Server działający na porcie domyślnym 1433. Należy również zwrócić uwagę, że ustawiono flagi Acknowledgement field significant i Reset the connection. Mając doświadczenie w filtrowaniu śledzenia Monitora sieci, można odfiltrować wartości flag TCP według wartości szesnastkowej 0x14, aby wyświetlić na liście śledzenia Monitora sieci wyłącznie pakiety ACK+RESET.
Należy zwrócić uwagę, że podobne pakiety ACK+RESET można zauważyć również wtedy, gdy komputera z programem SQL Server w ogóle nie uruchomiono lub nie nasłuchuje on za pomocą protokołu TCP/IP, co powoduje, że pakiety ACK+RESET nie stanowią definitywnego potwierdzenia pojawienia się problemu. Jeśli wartość ustawienia WinsockListenBacklog jest zbyt niska, niektóre próby połączenia zakończą się odebraniem pakietów akceptacji, a inne próby połączenia w tej samej ramce czasu zakończą się natychmiastowym odebraniem pakietów ACK+RESET.
Należy pamiętać, że w bardzo rzadkich sytuacjach dopasowanie tego ustawienia może być konieczne nawet po włączeniu buforowania na komputerach klienckich. Na przykład jeśli wiele komputerów klienckich komunikuje się z pojedynczym komputerem, na którym uruchomiono program SQL Server, w konkretnym okresie, nawet po włączeniu buforowania, może nastąpić równocześnie duża liczba prób połączenia.
Uwaga Nie trzeba uruchamiać ponownie systemu Windows, aby zmiana ustawienia WinsockListenBacklog została uwzględniona. Wystarczy zatrzymać i uruchomić ponownie usługę SQL Server. Ustawienie rejestru WinsockListenBacklog dotyczy tylko komputera, na którym uruchomiono program SQL Server. Nie ma ono żadnego wpływu na żaden komputer kliencki komunikujący się z programem SQL Server.
