Сводка
При использовании драйвера ODBC SQL Server, поставщика SQL Server OLE DB или управляемого поставщика System.Data.SqlClient можно отключить пулы подключений с помощью соответствующих интерфейсов программирования приложений (API). При отключении пула нагрузка на базовую сетевую библиотеку SQL Server может быть увеличена, если приложение часто открывает и закрывает подключения. В этой статье описываются некоторые параметры TCP/IP, которые, возможно, потребуется изменить в этих условиях.
Дополнительные сведения
Отключение пулов может привести к быстрому открытию и закрытию новых подключений сокетов к компьютеру, на котором выполняется SQL Server, базовый сетевой драйвер SQL Server. Чтобы справиться с более высоким уровнем нагрузки, может потребоваться изменить параметры сокета TCP/IP по умолчанию для операционной системы и компьютера, на котором выполняется SQL Server.
Обратите внимание, что в этой статье рассматриваются только параметры, влияющие на сетевую библиотеку SQL Server при использовании протокола TCP/IP. Отключение пула также может вызвать проблемы, связанные со стрессом, в других протоколах SQL Server, таких как именованные каналы, но в этой статье этот раздел не рассматривается. Эта статья предназначена только для опытных пользователей. Если вы не понимаете темы, приведенные в этой статье, корпорация Майкрософт рекомендует просмотреть хорошую книгу о сокетах TCP/IP.
Обратите внимание, что корпорация Майкрософт настоятельно рекомендует всегда использовать пул с драйверами SQL Server. Использование пулов значительно повышает общую производительность как на стороне клиента, так и на стороне SQL Server при использовании драйверов SQL Server. Использование пулов также значительно сокращает сетевой трафик к компьютеру, на котором выполняется SQL Server. Например, пример теста, использующий 20 000 SQL Server подключения, открывается и закрывается с включенным пулом, использующий около 160 сетевых пакетов TCP/IP, что в общей сложности составляет 23 520 байт сетевой активности. Если пул отключен, тот же пример теста создал 225 129 сетевых пакетов TCP/IP, что в общей сложности составляет 27 209 622 байт сетевой активности.
Обратите внимание, что при возникновении проблем с сокетом TCP/IP, связанных со стрессом, в сетевых библиотеках SQL Server может появиться одно или несколько из следующих сообщений об ошибке при попытке подключиться к компьютеру под управлением SQL Server:
Примечание
SQL Server не существует или доступ запрещен
Примечание
Истекло время ожидания
Примечание
Общая ошибка сети
Примечание
Поставщик TCP. Обычно разрешено только одно использование каждого адреса сокета (протокол, сетевой адрес или порт).
Обратите внимание, что эти конкретные сообщения об ошибках также можно получать при возникновении других проблем с SQL Server. Например, эти сообщения об ошибках могут возникать, если удаленный компьютер под управлением SQL Server выключен, если удаленный компьютер под управлением SQL Server вообще не прослушивает сокеты TCP/IP, если сетевое подключение к компьютеру, на котором выполняется работа. SQL Server не работает, так как сетевой кабель вытаскиваются или возникают проблемы с разрешением DNS. В основном все, что может привести к сбою клиента при открытии сокета TCP/IP на компьютере под управлением SQL Server также может вызвать сообщения об ошибках. Однако при проблеме сокета, связанной со стрессом, проблема возникает периодически по мере того, как стресс возрастает и падает. Компьютер может работать в течение нескольких часов без ошибок, затем ошибка возникает один или два раза, а затем компьютер работает в течение нескольких часов без ошибок. Кроме того, при наличии этой проблемы общее подключение к SQL Server работает один момент времени, сбой следующего, а затем снова работает в следующий момент. Другими словами, проблемы сокетов, связанные со стрессом, обычно возникают спорадически, но реальные проблемы с сетевым подключением с SQL Server обычно не возникают спорадически.
При отключении пула при использовании протокола TCP/IP SQL Server обычно возникают две основные проблемы, связанные со стрессом: на клиентском компьютере могут быть отключены анонимные порты или превышено значение по умолчанию WinsockListenBacklog на компьютере, на котором выполняется SQL Server.
Чтобы получить дополнительные сведения об анонимных портах, щелкните номер статьи ниже, чтобы просмотреть статью в базе знаний Майкрософт:
319502 PRB: сообщение об ошибке "WSAEADDRESSINUSE" при попытке подключиться через анонимный порт после увеличения лимита подключения IMAP
Настройка параметров MaxUserPort и TcpTimedWaitDelay
Обратите внимание, что параметры MaxUserPort и TcpTimedWaitDelay применимы только для клиентского компьютера, который быстро открывает и закрывает подключения к удаленному компьютеру, на котором выполняется SQL Server и который не использует пул подключений. Например, эти параметры применяются на сервере служб IIS, который обслуживает большое количество входящих HTTP-запросов и открывает и закрывает подключения к удаленному компьютеру под управлением SQL Server и использует протокол TCP/IP с отключенным пулом. Если использование пулов включено, вам не нужно настраивать параметры MaxUserPort и TcpTimedWaitDelay.
При использовании протокола TCP/IP для открытия подключения к компьютеру, на котором выполняется SQL Server, базовая сетевая библиотека SQL Server открывает сокет TCP/IP для компьютера, на котором выполняется SQL Server. При открытии этого сокета сетевая библиотека SQL Server не включает параметр сокета TCP/IP SO_REUSEADDR. Дополнительные сведения о параметре сокета SO_REUSEADDR см. в разделе "Setsockopt" в Microsoft Developer Network (MSDN).
Обратите внимание, что сетевая библиотека SQL Server специально не включает параметр сокета TCP/IP SO_REUSEADDR по соображениям безопасности. Если SO_REUSEADDR включен, злоумышленник может захватить порт клиента для SQL Server и использовать учетные данные, которые предоставляет клиент, чтобы получить доступ к компьютеру, на котором выполняется SQL Server. По умолчанию, так как сетевая библиотека SQL Server не включает параметр сокета SO_REUSEADDR, при каждом открытии и закрытии сокета через сетевую библиотеку SQL Server на стороне клиента сокет переходит в состояние TIME_WAIT на четыре минуты. Если вы быстро открываете и закрываете SQL Server подключения через TCP/IP с отключенным пулом, вы быстро открываете и закрываете сокеты TCP/IP. Иными словами, каждое подключение SQL Server имеет один сокет TCP/IP. Если вы быстро откроете и закроете 4000 сокетов менее чем за четыре минуты, вы достигнете максимального значения по умолчанию для анонимных портов клиента, и новые попытки подключения к сокетам завершаются ошибкой до истечения времени ожидания существующего набора сокетов TIME_WAIT.
На стороне клиента может потребоваться увеличить параметры MaxUserPort и TcpTimedWaitDelay, которые обсуждаются в Q319502 при отключенном пуле. Параметры этих значений определяются тем, сколько SQL Server подключение открывается и закрывается на стороне клиента. Вы можете проверить, сколько клиентских портов находятся в состоянии TIME_WAIT с помощью средства Netstat на клиентском компьютере. Запустите средство Netstat с флагом -n, как показано ниже, и подсчитайте количество клиентских сокетов для SQL Server IP-адреса, которые находятся в TIME_WAIT состоянии. В этом примере IP-адрес удаленного компьютера под управлением SQL Server — 10.10.10.20, IP-адрес клиентского компьютера — 10.10.10.10, а три установленных подключения и два подключения находятся в TIME_WAIT состоянии:
C:\>netstat -n
Active Connections
Proto Local Address Foreign Address State
TCP 10.10.10.10:2000 10.10.10.20:1433 ESTABLISHED
TCP 10.10.10.10:2001 10.10.10.20:1433 ESTABLISHED
TCP 10.10.10.10:2002 10.10.10.20:1433 ESTABLISHED
TCP 10.10.10.10:2003 10.10.10.20:1433 TIME_WAIT
TCP 10.10.10.10:2004 10.10.10.20:1433 TIME_WAIT
Если вы запустите netstat -n и увидите, что к IP-адресу целевого компьютера, на котором выполняется около 4000 подключений, SQL Server находятся в TIME_WAIT состоянии, можно как увеличить параметр MaxUserPort по умолчанию, так и уменьшить параметр TcpTimedWaitDelay, чтобы не иссякли анонимные порты клиента. Например, можно задать для параметра MaxUserPort значение 20000, а для параметра TcpTimedWaitDelay — значение 30. Более низкий параметр TcpTimedWaitDelay означает, что сокеты ожидают в TIME_WAIT состоянии меньше времени. Более высокий параметр MaxUserPort означает, что в TIME_WAIT состоянии можно использовать больше сокетов.
Обратите внимание, что при настройке параметра MaxUserPort или TcpTimedWaitDelay необходимо перезапустить Microsoft Windows, чтобы новый параметр вступил в силу. Параметры MaxUserPort и TcpTimedWaitDelay предназначены для любого клиентского компьютера, который взаимодействует с компьютером, на котором выполняется SQL Server через сокеты TCP/IP. Эти параметры не действуют, если они заданы на компьютере под управлением SQL Server если вы не устанавливаете локальные подключения сокетов TCP/IP к локальному компьютеру, на котором выполняется SQL Server.
Примечание. При настройке параметра MaxUserPort рекомендуется зарезервировать порт 1434 для использования службой браузера SQL Server (sqlbrowser.exe). Дополнительные сведения о том, как это сделать, щелкните следующий номер статьи, чтобы просмотреть статью в базе знаний Майкрософт:
812873 Как зарезервировать диапазон временных портов на компьютере под управлением Windows Server 2003 или Windows 2000 Server
Настройка параметра WinsockListenBacklog
Дополнительные сведения об этом SQL Server параметре реестра щелкните номер статьи ниже, чтобы просмотреть статью в базе знаний Майкрософт:
154628 INF: журналы SQL 17832 с несколькими запросами на подключение TCP\IP
Когда сетевая библиотека SQL Server прослушивает сокеты TCP/IP, сетевая библиотека SQL Server использует API Winsock прослушивания. Вторым параметром ДЛЯ API прослушивания является невыполненная работа, разрешенная для сокета. Эта невыполненная работа представляет максимальную длину очереди ожидающих подключений для прослушивателя. Если длина очереди превышает эту максимальную длину, сетевая библиотека SQL Server немедленно отклоняет дополнительные попытки подключения сокета TCP/IP. Кроме того, сетевая библиотека SQL Server отправляет пакет ACK+RESET.
SQL Server 2000 использует параметр невыполненной работы по умолчанию 5. Это означает, что компьютер, на котором выполняется SQL Server, передает значение 5 параметру невыполненной работы API Winsock, когда API прослушивания настраивает потоки прослушивания протокола TCP/IP на компьютере, на котором выполняется SQL Server. Вы можете настроить раздел реестра WinsockListenBacklog, чтобы указать другое значение, передаваемое для этого параметра. Начиная с SQL Server 2005 г. сетевая библиотека передает значение SOMAXCONN в качестве параметра невыполненной работы в API прослушивания. SOMAXCONN позволяет поставщику Winsock задать максимально допустимое значение для этого параметра. Таким образом, раздел реестра WinsockListenBacklog больше не используется и не требуется в SQL Server 2005 г.
Параметр невыполненной работы работает следующим образом: предположим, что произвольная служба прослушивает входящие запросы сокета TCP/IP. Если для параметра невыполненной работы задано значение 5 и многие запросы на подключение к сокету постоянно передаются, служба может не отвечать на входящие запросы так быстро, как они поступают. На этом этапе уровень сокетов TCP/IP помещает эти входящие запросы в очередь невыполненной работы, и служба может позже вытащить запросы из этой очереди и обработать входящий запрос на подключение сокета. После заполнения очереди уровень сокетов TCP/IP немедленно отклоняет все дополнительные запросы сокетов, поступающие в систему, отправляя клиенту пакет ACK+RESET. Увеличение размера очереди невыполненной работы увеличивает число ожидающих запросов на подключение к сокету, которые уровень сокетов TCP/IP помещает в очереди перед отклонением запросов.
Обратите внимание, что параметр WinsockListenBacklog предназначен для SQL Server. SQL Server пытается прочитать этот параметр реестра при первом запуске службы SQL Server. Если параметр не существует, используется значение по умолчанию 5. Если параметр реестра существует, SQL Server считывает параметр и использует указанное значение в качестве параметра невыполненной работы при вызове прослушивания API WinSock, так как потоки прослушивания сокета TCP/IP настроены внутри SQL Server.
Чтобы определить, возникла ли эта проблема, можно запустить трассировку сетевого монитора на клиенте или компьютере, на котором выполняется SQL Server, и найти запросы на подключение к сокету, которые немедленно отклоняются с помощью ACK+RESET. При проверке пакетов TCP/IP в сетевом мониторе при возникновении этой проблемы вы увидите следующий пакет:
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)
Обратите внимание, что исходный порт 0x599 или 1433 в десятичном формате. Это означает, что пакет поступает с типичного компьютера, на котором работает SQL Server и работает на порте по умолчанию 1433. Кроме того, обратите внимание, что поле Подтверждение имеет важное значение и установлены флаги сброса подключения. Если вы знакомы с фильтрацией трассировки сетевого монитора, вы можете отфильтровать значение tcp-флагов по 0x14 шестнадцатеричным, чтобы увидеть только пакеты ACK+RESET в трассировке сетевого монитора.
Обратите внимание, что вы также можете увидеть аналогичные пакеты ACK+RESET, если компьютер, работающий под управлением SQL Server, не работает вообще или компьютер под управлением SQL Server не прослушивает протокол TCP/IP, поэтому наличие пакетов ACK+RESET не является определенным подтверждением этой проблемы. Если winsockListenBacklog слишком низок, некоторые попытки подключения получают пакеты приема, а некоторые подключения немедленно получают пакеты ACK+RESET за тот же период времени.
Обратите внимание, что в очень редких случаях может потребоваться настроить этот параметр, даже если на клиентских компьютерах включено объединение пулов. Например, если многие клиентские компьютеры разговаривают с одним компьютером под управлением SQL Server, в любой момент времени может произойти большое количество одновременных попыток входящего подключения, даже если включено использование пулов.
Примечание. Если вы настроили параметр WinsockListenBacklog, не нужно перезапускать Windows, чтобы этот параметр вступил в силу. Просто остановите и перезапустите службу SQL Server, чтобы параметр вступил в силу. Параметр реестра WinsockListenBacklog предназначен только для компьютера, на котором выполняется SQL Server. Это не влияет на любой клиентский компьютер, который разговаривает с SQL Server.