Toneladas de conexões TCP no estado TIME_WAIT no Windows 2008 - em execução na Amazon AWS

Question

SO: Windows Server 2008, SP2 (em execução no EC2 Amazon).

Execução de aplicativo da Web usando o Apache httpd & servidor tomcat 6.02 e servidor Web tem configurações de manutenção.

Existem cerca de 69.250 (porta http 80) + 15.000 (além da porta 80) conexões TCP no estado TIME_WAIT (usado netstat & tcpview). Essas conexões não parecem fechar mesmo depois de parar o servidor web (esperou 24 horas)

Contadores do monitor de desempenho:

• Conexões ativas do 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 tem a chave TcpTimedWaitDelay, então value deve ser o padrão (2 * MSL, 4 mins)

Mesmo se houver milhares de solicitações de conexão chegando ao mesmo tempo, por que o Windows OS não consegue limpá-las eventualmente?
Quais poderiam ser as razões por trás dessa situação?
Existe alguma maneira de fechar todas as conexões TIME_WAIT sem reiniciar o sistema operacional Windows?

Após alguns dias, o aplicativo para de fazer novas conexões.

    

Answer 1

Também lidamos com essa questão. Parece que a Amazon encontrou a causa raiz e a corrigiu. Aqui está a informação que eles me deram.

Hi, I am pasting below an explanation of what was causing this issue. Good news is that this has been fixed very recently by our engineering team. To get fix, all you'll have to do is STOP/START the Windows Server 2008 instances where you are seeing this issue. Again, I am not talking about REBOOT which is different. STOP/START causes the instance to move to a different (healthy) host. When these instances launch again, they will be running on hosts that have the fix in place so they won't have this issue again. Now below is the engineering explanation of this issue. After an in depth investigation, we've found that when running Windows 2008 x64 on most available instance types, we've identified an issue which may result in TCP connections that remain in TIME_WAIT/CLOSE_WAIT for excessively long periods of time (in some cases, remaining in this state indefinitely). While in these states, the particular socket pairs remain unusable and if enough accumulate, will result in port exhaustion for the ports in question. If this particular circumstance occurs, the only solution to clear the socket pairs in question is to reboot the instance in question. We have determined the cause to be the values produced by a timer function in Windows 2008 kernel API which, on many of our 64-bit platforms, will occasionally retrieve a value that is extremely far in the future. This affects the TCP stack by causing the timestamps on the TCP socket pairs to be stamped significantly far in the future. According to Microsoft, there is a stored cumulative counter which will not be updated unless the value produced by this API call is larger than the cumulative value. The ultimate result is that sockets created after this point will all be stamped too far in the future until that future time is reached. In some cases, we have seen this value several hundred days into the future, thus the socket pairs appear to be stuck forever.

    

Answer 2

A resposta de Ryan é um bom conselho geral, exceto que não se aplica à condição de Ravi no EC2. Nós também vimos este problema e por alguma razão o Windows está ignorando completamente o TcpTimedWaitDelay e nunca liberando o socket de seu estado TIMED_WAIT.

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

    

Answer 3

Eu encontrei esse segmento completamente aleatoriamente enquanto procurava depurar um problema separado, mas esse é um problema pequeno, mas bem conhecido, com o Windows no EC2. Costumávamos ter suporte premium e discutimos isso com eles em um ambiente não público por meio desse canal, mas esta é uma questão relacionada que nós fizemos discutir nos fóruns públicos .

Como outros já mencionaram, você precisa ajustar o Windows Servers imediatamente. No entanto, da mesma forma que o StopWatch não está funcionando no thread acima, a pilha TCP / IP também usa a chamada QueryPerformanceCounter para determinar exatamente quando o período TCP_TIME_WAIT deve durar. O problema é que, no EC2, eles encontraram e conhecem um problema no qual QueryPerformanceCounter fica descontrolado e pode retornar tempos bem 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. Quando rodando em uma configuração httpd, você pode ver como você rapidamente acumula esses sockets zumbis quando o estado é encontrado (geralmente vemos que este é um evento discreto, não que você lentamente acumule zumbis).

O que fazemos é executar um serviço em segundo plano que consulta o número de soquetes no estado TIME_WAIT e, quando isso passa por um determinado limite, tomamos uma ação (reinicialize o servidor). De alguma forma em os últimos 45 segundos , alguém apontou que você pode parar / iniciar o servidor para corrigir o problema - sugiro que você junte essas duas abordagens.

    

Answer 4

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

Para obter o melhor da sua máquina Windows, quando usado como um servidor HTTP, existem alguns parâmetros que você normalmente faria, como MaxUserPort TcpTimedWaitDelay, TcpAckFrequency, EnableDynamicBacklog, KeepAliveInterval, etc

Eu escrevi uma nota para mim sobre isso há alguns anos , apenas no caso de eu precisar de alguns padrões rápidos para começar. Sinta-se à vontade para entender os parâmetros e ajustá-los.

    

Answer 5

Não relacionado à AWS, acabamos de encontrar esse problema, parece que é resultado desse artigo da base de conhecimento:

link

Basicamente, ele entra em ação se um sistema estiver ativo por > 497 dias e o hotfix não tiver sido aplicado. É claro que a reinicialização foi cancelada - talvez não saibamos pelos próximos 16 meses se o hotfix funcionou, mas isso pode ajudar qualquer pessoa que tenha servidores de longa data disponíveis.

    

Answer 6

Eu estava experimentando quase 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). Eu esbarrei em esta resposta que referenciava um KB na Microsoft e um hotfix se os servidores estivessem sendo executados atrás de um balanceador de carga (quais são os meus). Depois de instalar o hotfix e reinicializar, todo o material CLOSE_WAIT foi resolvido.