Descrição de configurações de TCP/IP que talvez você precise ajustar ao pool de conexão do SQL Server está desativado

Traduções deste artigo Traduções deste artigo
ID do artigo: 328476 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

Neste artigo

Sumário

Quando você usa o driver ODBC do SQL Server, o SQL Server provedor OLE DB ou o provedor gerenciado System.Data.SqlClient, você pode desativar usando interfaces de programação as respectivo aplicativo (APIs) do pool de conexões. Quando você desabilita pool, a tensão na biblioteca de rede subjacente do SQL Server pode ser aumentada se seu aplicativo freqüentemente abre e fecha conexões. Este artigo descreve determinadas configurações de TCP/IP talvez você precise ajustar sob essas condições.

Mais Informações

Desligar o pool pode fazer com que o driver de rede subjacente do SQL Server abrir rapidamente e fechar novas conexões de soquete para o computador que está executando o SQL Server. Talvez você precise alterar configurações de soquete de TCP/IP padrão para o sistema operacional e o computador que está executando o SQL Server para lidar com os níveis superiores estresse.

Observe que este artigo apenas descreve as configurações que afetam a biblioteca de rede do SQL Server quando você usa o protocolo TCP/IP. Desativar pool também pode causar problemas relacionados ao estresse com outros protocolos do SQL Server, como pipes nomeados, mas este artigo não aborda esse tópico. Este artigo é apenas para usuários avançados. Se você não entende os tópicos neste artigo, a Microsoft recomenda que você vê um bom livro sobre soquetes TCP/IP.

Observe que a Microsoft recomenda fortemente que você use sempre pool com os drivers do SQL Server. Uso de pool muito melhora o desempenho geral tanto no cliente quanto no lado do SQL Server quando você usa os drivers do SQL Server. Usar pool também consideravelmente reduz tráfego de rede para o computador que está executando o SQL Server. Por exemplo, um teste de exemplo usado 20.000 SQL Server conexão abre e fecha com o pool de habilitado usado 160 sobre pacotes de rede TCP/IP, para um total de bytes 23,520 da atividade da rede. Com o pool de desativado, o mesmo teste de exemplo gerado 225,129 pacotes de rede TCP/IP, para um total de bytes 27,209,622 da atividade da rede.

Observe que quando você vir esses problemas de soquete relacionados ao estresse TCP/IP com as bibliotecas de rede do SQL Server, você pode receber uma ou mais das seguintes mensagens de erro quando você tenta se conectar a um computador que está executando o SQL Server:
SQL Server não existe ou acesso negado
Tempo limite expirou
Erro de rede geral
Provedor TCP: Somente uma utilização de cada endereço de soquete (protocolo/endereço de rede/porta) normalmente é permitida.
Observe que você também pode receber essas mensagens de erro específico quando estão ocorrendo outros problemas com o SQL Server; por exemplo, você pode receber essas mensagens de erro se o computador remoto que está executando o SQL Server é desligado, se o computador remoto que está executando o SQL Server não está escutando para soquetes TCP/IP, se for quebrada conectividade de rede com o computador que está executando o SQL Server porque o cabo de rede é retirado, ou se você estiver tendo problemas de resolução de DNS. Basicamente qualquer coisa que pode fazer com que o cliente não consiga abrir um soquete TCP/IP para o computador que está executando o SQL Server também pode causar as mensagens de erro. No entanto, com um problema de soquete relacionados ao estresse, o problema ocorre intermitentemente como a sobrecarga aumenta e cai. O computador pode executar por horas sem erros, o erro ocorre uma ou duas vezes e o computador e é executado para várias horas mais sem erros. Além disso, quando você tiver esse problema, geral conectividade para SQL Server funciona um instante, falha na próxima e novamente funciona instantâneas próximo. Em outras palavras, problemas relacionados ao estresse soquete normalmente ocorrem esporadicamente, mas real problemas de conectividade de rede com o SQL Server geralmente não ocorrem esporadicamente.

Dois problemas relacionados ao estresse principais normalmente ocorrem quando você desabilitar o pool enquanto você usa o protocolo TCP/IP do SQL Server: você poderá ser executado fora do portas anônimas no computador cliente ou você pode exceder a configuração de WinsockListenBacklog padrão no computador que está executando o SQL Server.

Para obter informações adicionais sobre portas anônimas, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
319502PROBLEMA: Mensagem de erro 'WSAEADDRESSINUSE' ao tentar conectar por meio de uma porta anônima após você aumentar o limite de conexão de IMAP

Ajuste as configurações de MaxUserPort e TcpTimedWaitDelay

Observe que as configurações de MaxUserPort e TcpTimedWaitDelay aplicável somente para um computador cliente que é rapidamente abrindo e fechando conexões com um computador remoto que está executando o SQL Server e que não está usando o pool de conexão. Por exemplo, essas configurações são aplicáveis em um servidor de Internet Information Services (IIS) que está servindo um grande número de solicitações HTTP de entrada e que está abrindo e fechando conexões a um computador remoto que está executando o SQL Server e usando o protocolo TCP/IP com o pool de desativado. Se o pooling estiver ativado, não é necessário ajustar as configurações de MaxUserPort e TcpTimedWaitDelay .

Quando você usar o protocolo TCP/IP para abrir uma conexão a um computador que está executando o SQL Server, a biblioteca de rede subjacente do SQL Server abre um soquete TCP/IP para o computador que está executando o SQL Server. Ao ser aberto neste soquete, a biblioteca de rede do SQL Server não permite a opção de soquete TCP/IP SO_REUSEADDR . Para obter mais informações sobre a configuração de soquete SO_REUSEADDR , consulte o tópico "Setsockopt" no Microsoft Developer Network (MSDN).

Observe que a biblioteca de rede do SQL Server especificamente não habilita a opção de soquete TCP/IP SO_REUSEADDR por razões de segurança. Quando SO_REUSEADDR estiver habilitada, um usuário mal-intencionado pode seqüestrar uma porta de cliente para o SQL Server e usar as credenciais que o cliente fornece para obter acesso ao computador que está executando o SQL Server. Por padrão, porque a biblioteca de rede do SQL Server não permite a opção de soquete SO_REUSEADDR , sempre que você abrir e fechar um soquete por meio da biblioteca de rede do SQL Server no lado do cliente, o soquete insere um estado TIME_WAIT por quatro minutos. Se você estiver rapidamente abertura e fechando conexões do SQL Server sobre TCP/IP com o pool de desativado, você rapidamente é abrir e fechar os soquetes TCP/IP. Em outras palavras, cada conexão do SQL Server tem um soquete TCP/IP. Se você rapidamente abrir e fechar 4000 soquetes em menos de quatro minutos, você atingirá a configuração máxima padrão para as portas anônimo do cliente e novo tentativas de conexão de soquete falharem até que o conjunto existente de soquetes TIME_WAIT expira.

No lado do cliente, talvez você precise aumentar as configurações MaxUserPort e TcpTimedWaitDelay abordadas Q319502 quando você tem pool desativado. As configurações para esses valores são determinadas por quantos conexão do SQL Server abre e fecha ocorre no lado do cliente. Você pode examinar quantas portas do cliente estão em um estado TIME_WAIT usando a ferramenta Netstat no computador cliente. Execute a ferramenta Netstat com o sinalizador - n da seguinte maneira e contar o número de soquetes de cliente para seu endereço IP do servidor SQL que estão em um estado TIME_WAIT. Neste exemplo, o endereço IP do computador remoto que está executando o SQL Server é 10.10.10.20, o endereço IP do computador cliente é 10.10.10.10 e três conexões estabelecidas e duas conexões estão em um estado 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
				
se você executar netstat - n e verá que próximo a 4000 conexões com o IP endereço do computador de destino que está executando o SQL Server estão em um estado TIME_WAIT, você pode tanto aumentar a configuração de MaxUserPort padrão e reduzir a configuração de TcpTimedWaitDelay para que você não executar check-out de portas anônimo do cliente. Por exemplo, você pode definir a configuração de MaxUserPort para 20000 e defina a configuração de TcpTimedWaitDelay para 30. A configuração de TcpTimedWaitDelay inferior significa que os soquetes Aguarde no estado TIME_WAIT menos tempo. Uma configuração de MaxUserPort maior significa que você pode ter mais soquetes no estado TIME_WAIT.

Observe que, se você ajustar a configuração de MaxUserPort ou TcpTimedWaitDelay , você deve reiniciar o Microsoft Windows para a nova configuração entrem em vigor. As configurações de MaxUserPort e TcpTimedWaitDelay são para qualquer computador cliente que está falando com um computador que está executando o SQL Server sobre soquetes TCP/IP. Essas configurações não tem qualquer efeito se elas estiverem definidas no computador que está executando o SQL Server a menos que você está fazendo conexões de soquete TCP/IP locais ao computador local que está executando o SQL Server.

Observação Se você ajustar a configuração de MaxUserPort , recomendamos que você reservar porta 1434 para uso pelo serviço de navegador do SQL Server (sqlbrowser.exe). Para obter mais informações sobre como fazer isso, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
812873Como reservar um intervalo de portas efêmeras em um computador que esteja executando o Windows Server 2003 ou Windows 2000 Server

Ajustar a configuração WinsockListenBacklog

Para obter informações adicionais sobre essa configuração de registro específicas do SQL Server, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
154628INF: Logs SQL 17832 com solicitações de conexão TCP\IP múltiplas
Quando a biblioteca de rede do SQL Server escuta soquetes TCP/IP, a biblioteca de rede do SQL Server usa a escutar API Winsock. O segundo parâmetro para a escuta API é a lista de pendências que é permitida para o soquete. Esta lista de pendências representa o comprimento máximo da fila de conexões para o ouvinte pendentes. Quando o comprimento da fila excede esse comprimento máximo, a biblioteca de rede do SQL Server rejeita imediatamente mais tentativas de conexão de soquete TCP/IP. Além disso, a biblioteca de rede do SQL Server envia um pacote ACK + RESET.

SQL Server 2000 usa um padrão de escuta configuração lista de pendências de 5. Isso significa que o computador que está executando o SQL Server passar o valor 5 para o parâmetro lista de pendências da escutar Winsock API quando a escuta API configura os threads de escutando de protocolo TCP/IP no computador que está executando o SQL Server. Você pode ajustar a chave WinsockListenBacklog para especificar um valor diferente a ser passado para este parâmetro. A partir do SQL Server 2005, a biblioteca de rede passa um valor de SOMAXCONN como a configuração de registro posterior para a escuta API. SOMAXCONN permite que o provedor de Winsock definir um valor razoável máximo para essa configuração. Portanto, a chave de registro WinsockListenBacklog não é usada ou necessários no SQL Server 2005.

Lista de pendências definindo funciona da seguinte forma: suponha que um serviço arbitrário está escutando solicitações de soquete TCP/IP. Se você definir a configuração da lista de pendências para 5 e muitas solicitações de conexão de soquete são continuamente fluxo no, o serviço não poderá responder às solicitações de entrada tão rápidas como eles são provenientes. Nesse ponto, a camada de soquete TCP/IP filas essas solicitações na fila de registro posterior e o serviço pode receber as solicitações de check-out dessa fila e manipular a solicitação de conexão de soquete entrada mais tarde. Depois que a fila preenchida, a camada de soquete TCP/IP imediatamente rejeita quaisquer solicitações de soquete adicionais que vêm enviando um pacote ACK + RESET volta ao cliente. Aumentar o tamanho da fila lista de pendências aumenta que o número de pendentes conexão de soquete solicitações que a camada de soquete TCP/IP filas antes das solicitações são rejeitadas.

Observe que a configuração WinsockListenBacklog é específica para o SQL Server. SQL Server tenta ler essa configuração de registro quando o serviço SQL Server é iniciado pela primeira vez. Se a configuração não existir, o padrão de 5 será usado. Se a configuração do registro existir, o SQL Server lê a configuração e usa o valor fornecido como a configuração de registro posterior quando ouvir a API do WinSock é chamada conforme os segmentos de escutando de soquete TCP/IP são configurados dentro do SQL Server.

Para determinar se você está executando para esse problema, você pode executar um rastreamento do Monitor de rede no cliente ou no computador que está executando o SQL Server e procure solicitações de conexão de soquete que imediatamente são rejeitadas com uma ACK + RESET. Se você examinar pacotes TCP/IP no Monitor de rede, você verá um pacote, como o seguinte quando esse problema está ocorrendo:
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)
				
Observe que a porta de origem está 0x599 ou 1433 em decimal. Isso significa que o pacote proveniente de um computador típico que está executando o SQL Server e que está em execução a porta padrão de 1433. Observe também que o campo de confirmação e os sinalizadores de Redefinir a conexão estão definidos. Se você estiver familiarizado com a filtragem de um rastreamento do Monitor de rede, você pode filtrar o valor de sinalizadores TCP por 0 x 14 hexadecimal para ver apenas os pacotes ACK + RESET no rastreamento de Monitor de rede.

Observe que você também poderá ver pacotes ACK + RESET semelhantes se o computador que está executando o SQL Server não estiver executando ou se o computador que está executando o SQL Server não está escutando para protocolo TCP/IP, ver pacotes ACK + RESET não é definitivamente confirmação que você está tendo esse problema. Se o WinsockListenBacklog for muito baixa, alguns recebem tentativas de conexão aceitar pacotes e algumas conexões imediatamente receber pacotes ACK + RESET no mesmo período de tempo.

Observe que em casos muito raros, talvez você precise ajustar essa configuração mesmo pool estiver habilitada nos computadores cliente. Por exemplo, se vários computadores cliente estão falando com um único computador que está executando o SQL Server, um grande número de tentativas de conexão de entrada simultâneas pode ocorrer em um determinado momento mesmo pool esteja habilitado.

Observação Se você ajustar a configuração WinsockListenBacklog , não é necessário reiniciar o Windows para essa configuração para tenha efeito. Apenas pare e reinicie o serviço SQL Server para que a configuração tenha efeito. A configuração de registro WinsockListenBacklog é somente para o computador que está executando o SQL Server. Ele não tem qualquer efeito em qualquer computador cliente que está falando com o SQL Server.

Propriedades

ID do artigo: 328476 - Última revisão: quinta-feira, 1 de janeiro de 2009 - Revisão: 11.0
A informação contida neste artigo aplica-se a:
  • Microsoft ODBC Driver para Microsoft SQL Server 3.7
  • Microsoft OLE DB Provider for SQL Server
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft ADO.NET 1.0
  • Microsoft ADO.NET 1.1
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Workgroup Edition
Palavras-chave: 
kbmt kbinfo KB328476 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 328476

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com