Windows Server 2008 SP2 64 bits - Conexões TCP nunca são liberadas após TIME_WAIT

Question

Temos um problema com o Windows 2008 Datacenter edition SP2 de 64 bits. Temos um processo que está pesquisando com muita frequência e estabelecendo novas conexões TCP. O sistema fica em um estado em que terminamos com mais de 16k conexões no estado TIME_WAIT. O tempo limite padrão do sistema operacional é de 120 segundos, após o qual essas conexões devem desaparecer, mas isso nunca acontece. Essas conexões persistem e nunca são limpas mesmo após o processo de origem ter terminado há muito tempo (ainda estamos em conexões de 16k dois dias após o processo ter sido eliminado). O sistema operacional deve eliminá-los, mas isso não acontece.

Alguém viu esse comportamento e, em caso afirmativo, o que foi feito para resolvê-lo? Estamos cientes de como ajustar a pilha tcp para diminuir o tempo limite ou permitir mais conexões, mas esse não é o problema aqui.

Obrigado!

    

Answer 1

O Amazon EC2 teve um grande problema com isso. Eles recentemente corrigiram o bug. Talvez o mesmo problema se aplique na sua situação?

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

Existe um Artigo da Microsoft que descreve algumas formas para resolver isso. Ele geralmente vem de aplicativos mal codificados e não fecha as portas corretamente. Você precisa verificar quais aplicativos você instalou ou quais tarefas está realizando e desativando esses aplicativos para ver o que está causando o problema.

Para corrigir o problema, você também quer ver:

1. Aumentar o intervalo superior de portas efêmeras que são dinamicamente alocado para o soquete TCP / IP do cliente conexões.
2. Reduzir o cliente Tempo limite de conexão do soquete TCP / IP valor do valor padrão de 240 segundos (uma correção mais permanente)

Answer 3

Eu tive o mesmo problema com o Windows 2003 Server. Problema foi resolvido quando eu reiniciar a máquina após a mudança de parâmetro TCPIP registro .. Pode ser que você pode experimentá-lo no servidor 2008

    

Answer 4

Eu notei que esse problema é diferente quando a mesma VM (Windows 2008r2) é implantada em um servidor Intel ou AMD Magny-Cours VMware. Na AMD, as conexões permanecem em TIME_WAIT indefinidamente, nas máquinas Intel elas obedecem ao tempo limite padrão de 4 min TIME_WAIT.