Tengo configurado Apache como proxy inverso para un servidor de aplicaciones Java (GlassFish) y noté que hay alrededor de 100 conexiones en el estado CLOSE_WAIT incluso en un sistema de desarrollo inactivo:
sudo netstat -n -e -p -a -t | grep httpd | grep CLOSE_WAIT | wc -l
Estoy usando la siguiente configuración de proxy HTTP:
ProxyPass /myapp http://localhost:8080/myapp ttl=20 max=1 smax=0
ProxyPassReverse /myapp http://localhost:8080/myapp
¿Por qué todas estas conexiones están dando vueltas? Configuré "ttl=20 max=1 smax=0", así que pensé que todas las conexiones se limpiarían en un sistema inactivo. ¿El servidor de aplicaciones no está haciendo su parte para limpiar las conexiones?
Respuesta1
Esto es unproblema conocido con mod_proxy, desde 2011.
El ttl debe ser más corto que el keepalive de la aplicación, de modo que Apache siempre sea el primero en enviar un FIN.
Otra dificultad es que no está definido en qué momento se cerrará realmente la conexión.
ttl: tiempo de vida de las conexiones inactivas y las entradas del grupo de conexiones asociadas, en segundos. Una vez alcanzado este límite, no se volverá a utilizar una conexión; estará cerrado a lasalgún tiempo más tarde.
Respuesta2
Encontré un problema similar y estoy buscando un razonamiento con respecto a Apache. Sospecho que es la bifurcación de Apache.
En cuanto a la solución, utilicé Nginx que resolvió el problema CLOSE_WAIT. Sin embargo, el número de TIME_WAIT (20.000 aproximadamente) muestra que algo no está bien en la forma en que las aplicaciones Java manejan las conexiones. Con el servidor Nginx y la aplicación funciona mucho mejor.
Espero que alguien pueda mejorar esta respuesta con profundidad técnica.
Respuesta3
Estas conexiones CLOSE_WAIT están inactivas, es solo el servidor las que las mantiene en la pila tcp en caso de que les lleguen más paquetes. En los "buenos viejos tiempos", los servidores Solaris se quedaban sin descriptores de archivos si estos eran demasiado grandes y el sistema colapsaba. Tuvimos que aumentar la cantidad total de descriptores de archivos permitidos en el kernel y reducir el intervalo de limpieza de las conexiones CLOSE_WAIT.
Hoy en día, el número predeterminado de descriptores de archivos suele ser lo suficientemente grande como para ignorarlo. Pero la configuración de limpieza se puede reducir, por lo que se reducirá la cantidad de conexiones CLOSE_WAIT.
Es por la propia naturaleza de estos (Glassfish, Tomcat, JBoss,...) utilizar un número «grande» de conexiones y no reutilizarlas. Puedes ignorarlo con seguridad, en la mayoría de los casos.