Toneladas de conexiones TCP en estado TIME_WAIT en Windows 2008 - ejecutándose en Amazon AWS

Sistema operativo: Windows Server 2008, SP2 (que se ejecuta en EC2 Amazon).

Ejecutar la aplicación web con el servidor Apache httpd & tomcat 6.02 y el servidor web tiene una configuración de mantenimiento.

Hay alrededor de 69,250 (puerto http 80) + 15000 (que no sea el puerto 80) conexiones TCP en estado TIME_WAIT (netstat y tcpview usadas). Estas conexiones no parecen cerrarse incluso después de detener el servidor web (esperado 24 horas)

Contadores de monitor de rendimiento:

• Conexiones activas TCPv4: 145K
• Conexiones pasivas TCPv4: 475K
• Conexiones de falla TCPv4: 16K
• Restablecimiento de conexiones TCPv4: 23K

HKEY_LOCAL_MACHINE\System \CurrentControlSet\Services\Tcpip\Parameters no tiene la clave TcpTimedWaitDelay, por lo que el valor debe ser el predeterminado (2 * MSL, 4 minutos)

Incluso si hay miles de solicitudes de conexión al mismo tiempo, ¿por qué el sistema operativo Windows no puede limpiarlas eventualmente?
¿Cuáles podrían ser las razones detrás de esta situación?
¿Hay alguna forma de cerrar a la fuerza todas estas conexiones TIME_WAIT sin reiniciar el sistema operativo Windows?

Después de unos días, la aplicación deja de tomar conexiones nuevas.

También hemos estado lidiando con este problema. Parece que Amazon encontró la causa raíz y la corrigió. Aquí está la información que me dieron.

Hola, pego a continuación una explicación de lo que estaba causando este problema. La buena noticia es que nuestro equipo de ingenieros ha solucionado esto muy recientemente. Para obtener una solución, todo lo que tendrá que hacer es DETENER / INICIAR las instancias de Windows Server 2008 donde vea este problema. Nuevamente, no estoy hablando de REBOOT, que es diferente. STOP / START hace que la instancia se mueva a un host diferente (saludable). Cuando estas instancias se inicien nuevamente, se ejecutarán en hosts que tengan la solución en su lugar para que no vuelvan a tener este problema. Ahora a continuación se encuentra la explicación de ingeniería de este problema. Después de una investigación en profundidad, descubrimos que al ejecutar Windows 2008 x64 en la mayoría de los tipos de instancias disponibles, ' Hemos identificado un problema que puede provocar conexiones TCP que permanecen en TIME_WAIT / CLOSE_WAIT durante períodos de tiempo excesivamente largos (en algunos casos, permanecen en este estado indefinidamente). Mientras que en estos estados, los pares de sockets en particular permanecen inutilizables y si se acumulan lo suficiente, se producirá el agotamiento de los puertos en cuestión. Si ocurre esta circunstancia particular, la única solución para borrar los pares de sockets en cuestión es reiniciar la instancia en cuestión. Hemos determinado que la causa son los valores producidos por una función de temporizador en la API del kernel de Windows 2008 que, en muchas de nuestras plataformas de 64 bits, ocasionalmente recuperará un valor que está extremadamente lejos en el futuro. Esto afecta a la pila TCP al hacer que las marcas de tiempo en los pares de sockets TCP se marquen significativamente en el futuro. Según Microsoft, hay un contador acumulativo almacenado que no se actualizará a menos que el valor producido por esta llamada a la API sea mayor que el valor acumulativo. El resultado final es que los sockets creados después de este punto se estamparán demasiado lejos en el futuro hasta que se llegue a ese momento futuro. En algunos casos, hemos visto este valor varios cientos de días en el futuro, por lo que los pares de enchufes parecen estar atascados para siempre.

La respuesta de Ryan es un buen consejo general, excepto que no se aplica a la condición que Ravi está experimentando en EC2. También hemos visto este problema y, por cualquier motivo, Windows ignora por completo el TcpTimedWaitDelay y nunca libera el socket de su estado TIMED_WAIT.

Esperar no ayuda ... reiniciar la aplicación no ayuda ... el único remedio que hemos encontrado es reiniciar el sistema operativo. Realmente feo.

Encontré este hilo completamente al azar mientras buscaba depurar un problema por separado, pero este es un problema poco conocido pero conocido con Windows en EC2. Solíamos tener soporte de primera calidad, y discutido esto con ellos en un entorno que no es pública a través de ese canal, pero este es un tema relacionado que nos dimos a discutir en los foros públicos .

Como otros han mencionado, debe sintonizar los servidores de Windows de la caja. Sin embargo, de la misma manera que StopWatch no funciona en el subproceso anterior, la pila TCP / IP también usa la QueryPerformanceCounterllamada para determinar exactamente cuándo debe durar el período TCP_TIME_WAIT. El problema es que en EC2, se han encontrado y conocen un problema en el que se QueryPerformanceCountervuelve loco y pueden regresar tiempos muy, muy lejanos en el futuro; no es que se ignore su estado TIME_WAIT, es que el tiempo de vencimiento de TIME_WAIT es potencialmente años en el futuro. Cuando se ejecuta en una configuración httpd, puede ver cómo acumula rápidamente estos sockets de zombies una vez que se encuentra el estado (generalmente vemos que este es un evento discreto, no que acumule zombies lentamente).

Lo que hacemos es ejecutar un servicio en segundo plano que consulta la cantidad de sockets en el estado TIME_WAIT, y una vez que se sitúa sobre cierto umbral, tomamos medidas (reiniciamos el servidor). De alguna manera, en los últimos 45 segundos , alguien señaló que puede detener / iniciar el servidor para solucionar el problema; le sugiero que combine estos dos enfoques.

La configuración predeterminada para la pila TCP en Windows es, por decir lo menos, no óptima para los sistemas que van a alojar un servidor HTTP.

Para obtener lo mejor de su máquina Windows cuando se usa como un servidor HTTP, hay algunos parámetros que normalmente ajustaría, como MaxUserPort TcpTimedWaitDelay, TcpAckFrequency, EnableDynamicBacklog, KeepAliveInterval, etc.

Me había escrito una nota sobre esto hace unos años, en caso de que necesite algunos valores predeterminados rápidos para comenzar. Siéntase libre de comprender los parámetros y luego ajustarlos.

Sin relación con AWS, nos encontramos con este problema, parece ser el resultado de este artículo de KB:

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

Básicamente, se activa si un sistema está activo durante> 497 días y la revisión no se ha aplicado. Un reinicio, por supuesto, lo ha despejado: es posible que no sepamos durante los próximos 16 meses si la revisión funcionó, pero esto puede ayudar a cualquiera que tenga servidores de larga duración.

Experimenté casi exactamente lo mismo en varios cuadros con Windows Server 2008 R2 x64 con SP1, principalmente con CLOSE_WAIT (que es algo diferente a TIME_WAIT). Me encontré con esta respuesta que hacía referencia a un KB en Microsoft y una revisión si los servidores se ejecutaban detrás de un equilibrador de carga (que son los míos). Después de instalar la revisión y reiniciar, se resolvieron todas las cosas CLOSE_WAIT.