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 as interfaces de programação de aplicativo respectiva (APIs) do pool de conexões. Quando você desabilita o pool, a tensão na biblioteca de rede subjacente do SQL Server pode ser aumentada se seu aplicativo frequentemente abre e fecha conexões. Este artigo descreve algumas configurações de TCP/IP que talvez você precise ajustar sob essas condições.
Mais informações
Como desativar 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 as configurações de soquete TCP/IP padrão para o sistema operacional e o computador que está executando o SQL Server para lidar com o maior nível de 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 de 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 compreender os tópicos abordados neste artigo, a Microsoft recomenda que você consulte um bom livro sobre soquetes TCP/IP.
Observe que a Microsoft recomenda que você use sempre pool com os drivers do SQL Server. Usar o pool muito melhora o desempenho geral no lado do cliente e do lado do SQL Server quando você usa os drivers do SQL Server. Usar o pool também consideravelmente reduz o tráfego de rede no computador que está executando o SQL Server. Por exemplo, um teste de amostra usado 20.000 SQL Server conexão abre e fecha com o pool habilitada usados cerca de 160 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 27,209,622 bytes de atividade da rede.
Observe que quando você vir essas questões de soquete TCP/IP relacionados ao estresse 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 esteja executando o SQL Server:
SQL Server não existe ou acesso negado
Tempo limite expirou
Erro geral de rede
Provedor TCP: Normalmente é permitida apenas uma utilização de cada endereço de soquete (protocolo/rede endereço/porta).
Observe que você também pode receber essas mensagens de erro específicas quando outros problemas estejam ocorrendo com SQL Server; Por exemplo, você pode receber essas mensagens de erro se o computador remoto que esteja executando o SQL Server é desligado, se o computador remoto que esteja executando o SQL Server não está escutando para soquetes TCP/IP, se a conectividade de rede para o computador que está executando o SQL Server é interrompida porque o cabo de rede é puxado, ou se você estiver tendo problemas de resolução de DNS. Basicamente tudo o que pode fazer com que o cliente apresente uma falha ao abrir um soquete TCP/IP no computador que está executando o SQL Server também pode causar mensagens de erro. No entanto, um problema de soquete relacionados ao estresse, o problema ocorre intermitentemente conforme a carga aumenta e diminui. O computador pode executar por horas sem erros e o erro ocorre uma ou duas vezes e o computador e executa para várias horas sem erros. Além disso, quando você tiver esse problema, a conectividade geral para SQL Server funciona um instante, falha na próxima e funciona novamente o próximo instantâneo. Em outras palavras, problemas relacionados ao estresse soquete normalmente ocorrem esporadicamente, mas real problemas de conectividade de rede com o SQL Server normalmente não ocorrem esporadicamente.
Dois problemas principais relacionados ao estresse normalmente ocorrem quando você desabilitar o pool enquanto você usa o protocolo TCP/IP do SQL Server: talvez você fique sem portas anônimas no computador cliente ou pode exceder a configuração de WinsockListenBacklog padrão no computador que está executando o SQL Server.
Para obter informações adicionais sobre as portas anônimas, clique no número abaixo para ler o artigo na Base de Conhecimento da Microsoft:
319502 PRB: mensagem de erro 'WSAEADDRESSINUSE' ao tentar se conectar através de uma porta anônima após aumentar o limite de conexão IMAP
Ajustar as configurações de MaxUserPort e TcpTimedWaitDelay
Observe que as configurações de MaxUserPort e TcpTimedWaitDelay são aplicáveis apenas para um computador cliente que é rapidamente abrindo e fechando conexões a um computador remoto que esteja executando o SQL Server e que não está usando o pool de conexões. Por exemplo, essas configurações são aplicáveis em um servidor de serviços de informações da Internet (IIS) que está atendendo a um grande número de solicitações HTTP de entrada e que está abrindo e fechando conexões a um computador remoto que esteja executando o SQL Server e que esteja usando o protocolo TCP/IP com o pool de desativado. Se o pool estiver ativado, você não precisa ajustar as configurações de MaxUserPort e TcpTimedWaitDelay .
Quando você usa o protocolo TCP/IP para abrir uma conexão com um computador que esteja executando o SQL Server, a biblioteca de rede subjacente do SQL Server abre um soquete TCP/IP no computador que está executando o SQL Server. Ao abrir esse soquete, a biblioteca de rede do SQL Server não permite que 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 SQL Server especificamente não habilite 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 sequestrar uma porta do cliente para 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 que a opção de soquete SO_REUSEADDR , sempre que você abre e fecha um soquete por meio da biblioteca de rede do SQL Server no lado do cliente, o soquete entra em um estado TIME_WAIT por quatro minutos. Se você rapidamente abrindo e fechando conexões do SQL Server sobre TCP/IP com o pool de desativado, rapidamente estiver abrindo e fechando soquetes TCP/IP. Em outras palavras, cada conexão do SQL Server possui um soquete TCP/IP. Se você rapidamente abrir e fecha os 4000 soquetes em menos de quatro minutos, ajudará a alcançar a configuração máxima de padrão para as portas anônimo do cliente e novas tentativas de conexão de soquete falham até o conjunto existente de soquetes TIME_WAIT expira.
No lado do cliente, você terá que aumentar as configurações de MaxUserPort e TcpTimedWaitDelay abordadas Q319502 quando você tiver desabilitado o pool. As configurações para esses valores são determinadas por quantas conexões SQL Server abre e fecha ocorre no lado do cliente. Você pode examinar quantas portas de 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 do cliente para o seu endereço de IP do SQL Server que estão em um estado TIME_WAIT. Neste exemplo, o endereço IP do computador remoto que esteja executando o SQL Server é 10.10.10.20, o endereço IP do computador cliente é 10.10.10.10 e três estabelecer conexões 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 o netstat - n e verá que próximo 4000 conexões ao IP endereço do computador de destino que esteja executando o SQL Server estiver em um estado TIME_WAIT, for possível aumentar a configuração de MaxUserPort padrão e reduzir a configuração de TcpTimedWaitDelay para que você não fique sem 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 de sockets 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 tenha efeito. As configurações de MaxUserPort e TcpTimedWaitDelay são para qualquer computador cliente que está se comunicando com um computador que esteja executando o SQL Server sobre soquetes TCP/IP. Essas configurações não terá qualquer efeito se elas estiverem definidas no computador que está executando o SQL Server, a menos que você estiver 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 com o serviço 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 Conhecimento da Microsoft:
Como reservar um intervalo de portas efêmeras em um computador que esteja executando o Windows Server 2003 ou Windows 2000 Server 812873
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 Conhecimento da Microsoft:
154628 INF: SQL registra 17832 com solicitações de conexão TCP\IP múltiplas
Quando a biblioteca de rede SQL Server escuta em soquetes TCP/IP, a biblioteca de rede do SQL Server usa a ouvir API Winsock. O segundo parâmetro para a escuta API é a lista de pendências é 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 o comprimento máximo, a biblioteca de rede SQL Server rejeita imediatamente mais tentativas de conexão de soquete TCP/IP. Além disso, a biblioteca de rede SQL Server envia um pacote ACK + RESET.
SQL Server 2000 usa um padrão de escuta configuração de lista de pendências de 5. Isso significa que o computador que está executando o SQL Server passa o valor 5 para o parâmetro de lista de pendências da ouvir API Winsock quando a escuta API configura os threads de escuta de protocolo TCP/IP no computador que está executando o SQL Server. Você pode ajustar a chave de registro WinsockListenBacklog para especificar um valor diferente a ser passado para esse parâmetro. Iniciando no SQL Server 2005, a biblioteca de rede transmite um valor de SOMAXCONN como a configuração da lista de pendências para a escuta API. SOMAXCONN permite que o provedor Winsock definir um valor razoável máximo para essa configuração. Portanto, a chave de registro WinsockListenBacklog é não são mais usada ou necessários no SQL Server 2005.
A 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 quanto eles chegam. Neste ponto, a camada de soquete TCP/IP filas essas solicitações de entrada na fila de registro posterior e o serviço pode receber as solicitações de fila e lidar com a solicitação de conexão de soquete entrada mais tarde. Depois que a fila enche, a camada de soquete TCP/IP imediatamente rejeita quaisquer solicitações de soquete adicionais que chegam ao enviar um pacote ACK + RESET volta para o cliente. Aumentando a aumenta de tamanho de fila backlog que o número de pendentes conexão de soquete solicita que a camada de soquete TCP/IP filas antes que as solicitações são rejeitadas.
Observe que a configuração WinsockListenBacklog é específica para SQL Server. SQL Server tenta ler essa configuração do registro quando o serviço do SQL Server é iniciado pela primeira vez. Se a configuração não existir, será usado o padrão de 5. Se a configuração do registro existir, o SQL Server lê a configuração e usa o valor fornecido como a configuração da lista de pendências quando ouvir a API do WinSock é chamada como os threads de escuta de soquete TCP/IP estão definidos up dentro do SQL Server.
Para determinar se você está executando esse problema, você pode executar um rastreamento do Monitor de rede no cliente ou no computador que está executando o SQL Server e procure as solicitações de conexão de soquete são imediatamente rejeitadas com um ACK + RESET. Se você examinar os pacotes TCP/IP no Monitor de rede, você verá um pacote como o seguinte quando esse problema estiver ocorrendo:
Frame: Base frame propertiesETHERNET: 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 é 0x599 ou 1433 em decimal. Isso significa que o pacote vem de um típico computador que está executando o SQL Server e que está em execução a porta 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 0x14 hexadecimal para ver apenas os pacotes ACK + RESET no rastreamento de Monitor de rede.
Observe que você também pode ver pacotes ACK + RESET semelhantes se o computador que está executando o SQL Server não estiver funcionando ou se o computador que está executando o SQL Server não está escutando o protocolo TCP/IP, para que ver pacotes ACK + RESET não é definitiva confirmação que está tendo esse problema. Se a WinsockListenBacklog for muito baixa, alguns recebem tentativas de conexão aceitar pacotes e algumas conexões imediatamente recebem pacotes ACK + RESET no mesmo período.
Observe que em casos raros, talvez você precise ajustar essa configuração, mesmo se o pool estiver habilitada nos computadores cliente. Por exemplo, se vários computadores cliente estão se comunicando com um único computador que esteja executando o SQL Server, um grande número de tentativas de conexão de entrada simultâneas pode ocorrer em um determinado momento, mesmo se o pool estiver ativado.
Observação: Se você ajustar a configuração WinsockListenBacklog , não é necessário reiniciar o Windows para que essa configuração tenha efeito. Pare e reinicie o serviço do SQL Server para que a configuração tenha efeito. A configuração de registro WinsockListenBacklog é apenas para o computador que está executando o SQL Server. Ela não tem qualquer efeito em qualquer computador cliente que se comunica com o SQL Server.
