Descrição das definições de TCP/IP que poderá ter de ajustar quando o pooling de SQL Server está desactivado

Quando utiliza o controlador de ODBC para SQL Server, o SQL Server fornecedor de OLE DB ou o fornecedor gerido System.data.SqlClient, pode desactivar o pooling de ligações, utilizando as respectivas interfaces programação da aplicação (API) do. Quando desactiva o agrupamento, a carga na biblioteca de rede subjacente do SQL Server pode ser aumentada se frequentemente a aplicação abre e fecha ligações. Este artigo descreve algumas definições de TCP/IP que poderá ter de ajustar nestas condições.

Desligar agrupamento pode fazer com que o controlador de rede subjacente do SQL Server para rapidamente abrir e fechar ligações de socket novo ao computador que esteja a executar o SQL Server. Poderá ter de alterar predefinições de socket TCP/IP para o sistema operativo e no computador com o SQL Server para lidar com os níveis de pressão superiores.

Tenha em atenção que este artigo aborda apenas definições que afectam a biblioteca de rede do SQL Server quando utiliza o protocolo TCP/IP. Desactivar o agrupamento também pode causar problemas stress relacionados com outros protocolos de SQL Server como pipes nomeados, mas neste artigo não aborda este tópico. Este artigo é apenas para utilizadores avançados. Se não compreender os tópicos existentes neste artigo, a Microsoft recomenda que consulte um manual boa sobre TCP/IP sockets.

Repare que a Microsoft recomenda vivamente que utilize sempre agrupamento com os controladores do SQL Server. Utilizar agrupamento bastante melhora o desempenho global no lado do cliente e do lado do servidor SQL quando utiliza os controladores do SQL Server. Utilizar agrupamento também consideravelmente reduz o tráfego de rede para o computador com o SQL Server. Por exemplo, um teste de exemplo utilizado 20.000 SQL Server ligação abre e fecha com agrupamento activado utilizados cerca de 160 pacotes de rede TCP/IP, perfazendo um total de bytes 23,520 da actividade da rede. Com agrupamento desactivado, o mesmo teste de exemplo gerado 225,129 pacotes de rede TCP/IP, perfazendo um total de bytes 27,209,622 da actividade da rede.

Nota que quando vir estes problemas socket relacionadas com importância TCP/IP com bibliotecas de rede do SQL Server, poderá receber um ou mais das seguintes mensagens de erro quando tenta ligar a um computador que esteja a executar o SQL Server: Note que também pode receber estas mensagens de erro específico quando ocorrem outros problemas com o SQL Server; por exemplo, poderá receber estas mensagens de erro se o computador remoto que esteja a executar o SQL Server é encerrado, se o computador remoto que está a executar o SQL Server está a não escutar sockets de TCP/IP, se a ligação de rede ao computador que esteja a executar o SQL Server é interrompida porque o cabo de rede é retirado ou se estiver a ter problemas de resolução de DNS. Basicamente, tudo o que fazer com que o cliente não conseguir abrir um socket de TCP/IP ao computador que está a executar o SQL Server também pode causar mensagens de erro. No entanto, com um problema de socket relacionadas com importância, o problema ocorre intermitentemente a carga ultrapassa e ficar. O computador pode executar para horas sem erros, depois, o erro ocorre uma ou duas vezes e o computador para ser executada para vários mais horas sem erros. Além disso, quando tiver este problema, conectividade geral para SQL Server funciona um instantâneo, falha o seguinte e funciona novamente instantâneas seguinte. Por outras palavras, relacionadas com importância socket problemas ocorrem normalmente esporadicamente mas real problemas de conectividade de rede com o SQL Server, normalmente, a não ocorrem esporadicamente.

Dois problemas principais relacionadas com importância ocorrem normalmente quando desactivar o agrupamento enquanto utiliza o protocolo TCP/IP do SQL Server: poderá ficar sem portas anónimas no computador cliente ou pode exceder a definição de WinsockListenBacklog predefinida no computador que está a executar o SQL Server.

Para obter informações adicionais sobre portas anónimas, clique no número de artigo existente abaixo para visualizar o artigo na base de dados de conhecimento da Microsoft:

Ajuste as definições de MaxUserPort e TcpTimedWaitDelay

Note que as definições de MaxUserPort e TcpTimedWaitDelay são aplicáveis apenas um computador cliente que rapidamente abrir e fechar ligações a um computador remoto com o SQL Server e que não está utilizar agrupamento de ligações. Por exemplo, estas definições são aplicáveis num servidor dos serviços de informação Internet (IIS) que está a processar um grande número de pedidos de HTTP e que é abrir e fechar ligações a um computador remoto com o SQL Server e que utiliza o protocolo TCP/IP com agrupamento desactivado. Se o agrupamento estiver activado, não é necessário ajustar as definições de MaxUserPort e TcpTimedWaitDelay .

Quando utiliza o protocolo TCP/IP para abrir uma ligação a um computador que esteja a executar o SQL Server, a biblioteca de rede subjacente do SQL Server abre um socket de TCP/IP ao computador que está a executar o SQL Server. Quando abre este socket, a biblioteca de rede do SQL Server não activa a opção de socket de TCP/IP SO_REUSEADDR . Para obter mais informações sobre a definição de socket SO_REUSEADDR , consulte o tópico "Setsockopt" no Microsoft Developer Network (MSDN).

Tenha em atenção que a biblioteca de rede do SQL Server especificamente não activa a opção de socket de TCP/IP SO_REUSEADDR por motivos de segurança. Quando SO_REUSEADDR está activada, um utilizador mal intencionado pode assalte uma porta de cliente para o SQL Server e utilizar as credenciais que o cliente fornece para aceder ao computador que é a executar o SQL Server. Por predefinição, uma vez que a biblioteca de rede do SQL Server não activa a opção de socket SO_REUSEADDR , sempre que abrir e fechar um socket a biblioteca de rede do SQL Server do lado do cliente, o socket entra num estado TIME_WAIT para quatro minutos. Se estiver rapidamente abrir e fechar ligações do SQL Server através de TCP/IP com agrupamento desactivado, são rapidamente abrir e fechar os sockets de TCP/IP. Por outras palavras, cada ligação do SQL Server tem um socket de TCP/IP. Se rapidamente abre e fecha 4000 sockets em menor do que quatro minutos, visualizará a predefinição máxima para as portas anónimo do cliente e novas tentativas de ligação de socket falharem até que o conjunto de sockets TIME_WAIT existente tempo limite.

No lado do cliente, poderá ter de aumentar as definições MaxUserPort e TcpTimedWaitDelay descritos Q319502 quando tiver desactivado o agrupamento. As definições para estes valores são determinadas pela ligação do SQL Server quantas abre e fecha ocorre no lado do cliente. Pode examinar quantas portas de cliente estão num estado TIME_WAIT, utilizando a ferramenta Netstat no computador cliente. Execute a ferramenta Netstat com o sinalizador - n maneira e contar o número de sockets de cliente para o endereço IP do servidor de SQL que estão num estado TIME_WAIT. Neste exemplo, o endereço IP do computador remoto que esteja a executar o SQL Server é 10.10.10.20, o endereço IP do computador cliente é 10.10.10.10 e três ligações estabelecidas e duas ligações são no estado TIME_WAIT: se executar o netstat - n e verá que perto a 4000 ligações para o IP endereço do computador destino que está a executar o SQL Server num estado TIME_WAIT, pode tanto aumentam a MaxUserPort predefinida e reduzir a definição TcpTimedWaitDelay para que não são executados fora do cliente anónimo portas. Por exemplo, pode repor a definição de MaxUserPort 20000 e defina a definição de TcpTimedWaitDelay para 30. Uma definição de TcpTimedWaitDelay inferior significa que os sockets de esperar no estado TIME_WAIT menos tempo. Uma definição de MaxUserPort mais elevada significa que pode tem mais sockets no estado TIME_WAIT.

Tenha em atenção que se ajuste a definição MaxUserPort ou TcpTimedWaitDelay , tem de reiniciar Microsoft Windows para a nova definição surta efeito. As definições de MaxUserPort e TcpTimedWaitDelay são para qualquer computador cliente que está a falar para um computador com o SQL Server através de TCP/IP sockets. Estas definições não tem qualquer efeito se estiverem definidas no computador com o SQL Server, a menos que estiver a efectuar ligações de socket de TCP/IP locais ao computador local que esteja a executar o SQL Server.

Nota Se ajustar a definição de MaxUserPort , recomendamos que reservam a porta 1434 para utilização pelo serviço de browser de servidor SQL (sqlbrowser.exe). Para obter mais informações sobre como efectuar este procedimento, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base:

Rectifique os WinsockListenBacklog

Para obter informações adicionais sobre esta definição de registo específicas do SQL Server, clique no número de artigo existente abaixo para visualizar o artigo na base de dados de conhecimento da Microsoft: Quando a biblioteca de rede do SQL Server escuta em sockets de TCP/IP, a biblioteca de rede do SQL Server utiliza a ouvir API Winsock. O segundo parâmetro para o ouvir API é backlog permitido para o socket. Este backlog representa o comprimento máximo da fila de ligações para a escuta pendentes. Quando o comprimento da fila de excede este comprimento máximo, a biblioteca de rede do SQL Server rejeita imediatamente mais tentativas de ligação de socket de TCP/IP. Além disso, a biblioteca de rede do SQL Server envia um pacote ACK + RESET.

SQL Server 2000 utiliza uma predefinição escuta backlog definição de 5. Isto significa que o computador com o SQL Server transmite o valor 5 para o parâmetro backlog da ouvir API Winsock, quando o ouvir API configura os threads de escuta do protocolo TCP/IP no computador que está a executar o SQL Server. Pode ajustar a chave de registo WinsockListenBacklog para especificar um valor diferente a serem enviados para este parâmetro. A partir do SQL Server 2005, a biblioteca de rede transmite um valor de SOMAXCONN como definição backlog a ouvir API. SOMAXCONN permite ao fornecedor Winsock definir um valor razoável máximo para esta definição. Por conseguinte, a chave de registo WinsockListenBacklog já não utilizada ou necessários em SQL Server 2005.

Backlog definição funciona da seguinte forma: suponha que um serviço arbitrário vigia pedidos de socket de TCP/IP. Se definir a definição backlog para 5 e muitos pedidos de ligação de socket são continuamente transmissão em sequência no, o serviço não poderá responder a pedidos tão rápidos como vêm. Neste ponto, a camada de socket de TCP/IP coloca estes pedidos de entrada na fila de backlog e o serviço mais tarde pode solicitar os pedidos desta fila e processar o pedido de ligação de socket recebido. Depois da fila é preenchida, a camada de socket de TCP/IP imediatamente rejeita quaisquer pedidos de socket adicionais incluídos enviando um pacote ACK + RESET ao cliente. Aumentar a backlog fila tamanho aumenta que o número de pendentes ligação de socket de solicitações que a camada de socket de TCP/IP filas antes dos pedidos são rejeitados.

Note que a definição WinsockListenBacklog é específica de SQL Server. SQL Server tenta ler esta definição de registo quando o serviço SQL Server é iniciado pela primeira vez. Se a definição não existir, é utilizada a predefinição de 5. Se a definição de registo existir, o SQL Server lê a definição e utiliza o valor fornecido como a definição de backlog quando a API WinSock ouvir denomina-se que os threads escuta do socket de TCP/IP estiverem configurados no interior do SQL Server.

Para determinar se está a executar para este problema, pode executar um rastreio do Monitor de rede no cliente ou no computador que esteja a executar o SQL Server e procure a pedidos de ligação de socket são imediatamente rejeitados com um ACK + RESET. Se examinar os pacotes de TCP/IP no Monitor de rede, verá um pacote como a que se segue quando este problema ocorre: Note que a porta de origem é 0x599 ou 1433 em decimal. Isto significa que o pacote vem de um típico computador executa o SQL Server e que está em execução a porta predefinida de 1433. Repare também que o campo reconhecimento significativo e os sinalizadores de Repor a ligação estão definidos. Se estiver familiarizado com a filtragem um rastreio do Monitor de rede, pode filtrar o valor de sinalizadores de TCP por 0 x 14 hexadecimal para ver apenas os pacotes ACK + RESET num rastreio do Monitor de rede.

Tenha em atenção que também pode ver pacotes ACK + RESET semelhantes se o computador que esteja a executar o SQL Server não está a executar sequer ou se o computador que esteja a executar o SQL Server não está à escuta ao protocolo TCP/IP, sendo ver ACK + RESET pacotes não confirmação definitiva que está a ter este problema. Se WinsockListenBacklog for demasiado baixa, alguns ligação a receber tentativas aceitar pacotes e algumas ligações imediatamente ACK + RESET pacotes de recepção no período de tempo mesmo.

Repare que em casos raros, poderá ter de ajustar esta definição, mesmo se o agrupamento está activado nos computadores cliente. Por exemplo, se muitos computadores são falar com um único computador com o SQL Server, um grande número de tentativas de ligação a receber em simultâneo pode ocorrer em qualquer altura determinada mesmo se o agrupamento está activado.

Nota Se ajustar a definição WinsockListenBacklog , não é necessário reiniciar o Windows para esta definição surtam efeito. Apenas pare e reinicie o serviço SQL Server para que a definição entre em vigor. A definição de registo WinsockListenBacklog é apenas para o computador que esteja a executar o SQL Server. Não tem qualquer efeito em qualquer computador cliente que está a falar para SQL Server.