Toneladas de conexões TCP no estado TIME_WAIT no windows 2008 - executando na amazon AWS

SO: Windows Server 2008, SP2 (executando no EC2 Amazon).

A execução do aplicativo Web usando o servidor Apache httpd e tomcat 6.02 e o servidor Web possui configurações de manutenção.

Existem cerca de 69.250 (porta http 80) + 15000 (exceto a porta 80) conexões TCP no estado TIME_WAIT (usado netstat & tcpview). Essas conexões parecem não fechar mesmo após a interrupção do servidor da Web (esperou 24 horas)

Contadores de monitor de desempenho:

• Conexões ativas TCPv4: 145K
• Conexões passivas TCPv4: 475K
• Conexões de falha TCPv4: 16K
• Redefinição de conexões TCPv4: 23K

HKEY_LOCAL_MACHINE\System \CurrentControlSet\Services\Tcpip\Parameters não possui a chave TcpTimedWaitDelay, portanto, o valor deve ser o padrão (2 * MSL, 4 minutos)

Mesmo que existam milhares de solicitações de conexão ao mesmo tempo, por que o sistema operacional Windows não pode limpá-las eventualmente?
Quais poderiam ser as razões por trás dessa situação?
Existe alguma maneira de fechar com força todas essas conexões TIME_WAIT sem reiniciar o sistema operacional Windows?

Depois de alguns dias, o aplicativo para de fazer novas conexões.

Também estamos lidando com esse problema. Parece que a Amazon encontrou a causa raiz e a corrigiu. Aqui está a informação que eles me deram.

Olá, estou colando abaixo uma explicação do que estava causando esse problema. A boa notícia é que isso foi corrigido muito recentemente por nossa equipe de engenharia. Para obter a correção, basta interromper / iniciar as instâncias do Windows Server 2008 em que você está enfrentando esse problema. Mais uma vez, não estou falando de REBOOT, que é diferente. STOP / START faz com que a instância seja movida para um host diferente (íntegro). Quando essas instâncias forem iniciadas novamente, elas serão executadas em hosts que possuem a correção no local, para que não tenham esse problema novamente. Agora, abaixo, está a explicação de engenharia deste problema. Após uma investigação aprofundada, descobrimos que, ao executar o Windows 2008 x64 na maioria dos tipos de instância disponíveis, identificou um problema que pode resultar em conexões TCP que permanecem em TIME_WAIT / CLOSE_WAIT por períodos excessivamente longos (em alguns casos, permanecendo nesse estado indefinidamente). Enquanto nesses estados, os pares de soquetes específicos permanecem inutilizáveis ​​e, se acumularem o suficiente, resultarão em exaustão das portas em questão. Se essa circunstância específica ocorrer, a única solução para limpar os pares de soquetes em questão é reiniciar a instância em questão. Determinamos a causa como sendo os valores produzidos por uma função de timer na API do kernel do Windows 2008 que, em muitas de nossas plataformas de 64 bits, ocasionalmente recupera um valor extremamente distante no futuro. Isso afeta a pilha TCP, fazendo com que os carimbos de data e hora nos pares de soquetes TCP sejam carimbados significativamente longe no futuro. De acordo com a Microsoft, há um contador cumulativo armazenado que não será atualizado, a menos que o valor produzido por essa chamada de API seja maior que o valor cumulativo. O resultado final é que os soquetes criados após esse ponto serão carimbados demais no futuro até que o tempo futuro seja alcançado. Em alguns casos, vimos esse valor várias centenas de dias no futuro, portanto, os pares de soquetes parecem estar presos para sempre.

A resposta de Ryan é um bom conselho geral, exceto que não se aplica à condição que Ravi está enfrentando no EC2. Também vimos esse problema e, por qualquer motivo, o Windows ignora completamente o TcpTimedWaitDelay e nunca libera o soquete do estado TIMED_WAIT.

Esperar não ajuda ... reiniciar o aplicativo não ajuda ... o único remédio que encontramos é reiniciar o sistema operacional. Realmente feio.

Eu encontrei esse segmento completamente aleatoriamente enquanto procurava depurar um problema separado, mas esse é um problema pouco conhecido, mas conhecido no Windows no EC2. Estamos habituados a ter suporte premium, e discutiu isso com eles em um ambiente não-público através desse canal, mas este é um problema relacionado que se discutem nos fóruns públicos .

Como outros já mencionaram, você precisa ajustar os Servidores Windows imediatamente. No entanto, da mesma maneira que o StopWatch não está funcionando no encadeamento acima, a pilha TCP / IP também usa a QueryPerformanceCounterchamada para determinar exatamente quando o período TCP_TIME_WAIT deve durar. O problema é que, no EC2, eles encontraram e conhecem um problema que QueryPerformanceCounterdá errado, e pode retornar tempos distantes e distantes no futuro; não é que seu estado TIME_WAIT esteja sendo ignorado, é que o tempo de expiração de TIME_WAIT é potencialmente anos no futuro. Ao executar em uma configuração httpd, é possível ver como você acumula rapidamente esses soquetes zumbis quando o estado é encontrado (geralmente vemos que este é um evento discreto, não que você acumule zumbis lentamente).

O que fazemos é executar um serviço em segundo plano que consulta o número de soquetes no estado TIME_WAIT e, uma vez que isso paira sobre um determinado limite, agimos (reinicializamos o servidor). De alguma forma, nos últimos 45 segundos , alguém apontou que você pode parar / iniciar o servidor para corrigir o problema - sugiro que você junte essas duas abordagens.

As configurações padrão para a pilha TCP no Windows são, no mínimo, não ideais para sistemas que hospedam um servidor HTTP.

Para tirar o melhor proveito da sua máquina Windows quando usado como servidor HTTP, há alguns parâmetros que você normalmente ajustaria, como MaxUserPort TcpTimedWaitDelay, TcpAckFrequency, EnableDynamicBacklog, KeepAliveInterval etc.

Eu escrevi uma nota para isso sobre isso há alguns anos atrás, para o caso de precisar de alguns padrões rápidos para começar. Sinta-se livre para entender os parâmetros e depois ajustá-los.

Independentemente da AWS, acabamos de encontrar este problema, como resultado deste artigo da Base de Dados de Conhecimento:

http://support.microsoft.com/kb/2553549/en-us

Basicamente, ele entra em ação se um sistema estiver ativo por> 497 dias e o hotfix não foi aplicado. Uma reinicialização, é claro, a eliminou - talvez não saibamos nos próximos 16 meses se o hotfix funcionou, mas isso pode ajudar qualquer pessoa que tenha servidores de tempo de atividade por aí.

Eu estava experimentando exatamente a mesma coisa em várias caixas com o Windows Server 2008 R2 x64 com SP1, principalmente com CLOSE_WAIT (que é um pouco diferente de TIME_WAIT). Encontrei esta resposta que referenciava um KB na Microsoft e um hotfix se os servidores estivessem executando atrás de um balanceador de carga (quais são os meus). Depois de instalar o hotfix e reiniciar, todos os itens CLOSE_WAIT foram resolvidos.