Eu tenho a configuração do Apache como um proxy reverso para um servidor de aplicativos Java (GlassFish) e notei que existem cerca de 100 conexões no estado CLOSE_WAIT, mesmo em um sistema de desenvolvimento inativo:
sudo netstat -n -e -p -a -t | grep httpd | grep CLOSE_WAIT | wc -l
Estou usando as seguintes configurações de proxy HTTP:
ProxyPass /myapp http://localhost:8080/myapp ttl=20 max=1 smax=0
ProxyPassReverse /myapp http://localhost:8080/myapp
Por que todas essas conexões estão por aí? Eu configurei o "ttl = 20 max = 1 smax = 0", então imaginei que todas as conexões seriam limpas em um sistema ocioso. O servidor de aplicativos não está fazendo sua parte para limpar as conexões?
Este é um problema conhecido com o mod_proxy desde 2011.
O ttl precisa ser mais curto que o keepalive do aplicativo, para que o apache seja sempre o primeiro a enviar um FIN.
Outra dificuldade é que não é definido em que ponto a conexão será realmente fechada.
ttl - Time to live for inactive connections and associated connection pool entries, in seconds. Once reaching this limit, a connection will not be used again; it will be closed at some later time.
Eu encontrei um problema semelhante e estou procurando raciocinar com relação ao Apache. Eu suspeito do prefork do Apache.
Quanto à solução, usei o Nginx que resolveu o problema CLOSE_WAIT. No entanto, o número de TIME_WAIT (20.000 aprox.) Mostra que há algo incorreto na maneira como o (s) aplicativo (s) Java manipula conexões. Com o servidor e o aplicativo Nginx, o desempenho é muito melhor.
Espero que alguém possa melhorar esta resposta com profundidade técnica.
Essas conexões CLOSE_WAIT estão esgotadas, é apenas o servidor que as mantém na pilha tcp para o caso de mais pacotes chegarem a elas. Nos "bons e velhos tempos", os servidores Solaris ficariam sem descritores de arquivos se isso fosse muito grande e o sistema travasse. Tivemos que aumentar o número total de descritores de arquivos permitidos no kernel e reduzir o intervalo de limpeza das conexões CLOSE_WAIT.
Hoje em dia, o número padrão de descritores de arquivos geralmente é grande o suficiente para ignorar isso. Mas a configuração de limpeza pode ser reduzida, então o número de conexões CLOSE_WAIT será reduzido.
É pela própria natureza (Glassfish, Tomcat, JBoss, ...) usar um número "grande" de conexões e não reutilizá-las. Você pode ignorar com segurança, na maioria dos casos.
Tags glassfish apache-2.2 mod-proxy