Eu configurei o Apache como proxy reverso para um servidor de aplicativos Java (GlassFish) e notei que há cerca de 100 conexões no estado CLOSE_WAIT mesmo em um sistema de desenvolvimento ocioso:
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 "ttl=20 max=1 smax=0" então imaginei que todas as conexões seriam limpas em um sistema inativo. O servidor de aplicativos não está fazendo sua parte na limpeza das conexões?
Responder1
Isto é umproblema conhecido com mod_proxy, desde 2011.
O ttl precisa ser menor que o keepalive da aplicação, para que o apache seja sempre o primeiro a enviar um FIN.
Outra dificuldade é que não está definido em que ponto a conexão será efetivamente encerrada.
ttl - Tempo de vida para conexões inativas e entradas de pool de conexões associadas, em segundos. Ao atingir esse limite, a conexão não será utilizada novamente; estará fechado àsalgum tempo mais tarde.
Responder2
Encontrei um problema semelhante e estou procurando um raciocínio em relação ao Apache. Eu suspeito do pré-fork do Apache.
Quanto à solução, usei o Nginx que resolveu o problema CLOSE_WAIT. No entanto, o número de TIME_WAIT (20.000 aproximadamente) mostra que há algo errado com a maneira como os aplicativos Java lidam com as 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.
Responder3
Essas conexões CLOSE_WAIT estão inativas, é apenas o servidor que as mantém na pilha tcp, caso mais pacotes cheguem até elas. Nos "bons velhos tempos", os servidores Solaris ficariam sem descritores de arquivos se estes fossem muito grandes e o sistema travaria. 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 arquivo geralmente é grande o suficiente para ignorar isso. Mas a configuração de limpeza pode ser reduzida, portanto o número de conexões CLOSE_WAIT será reduzido.
É da própria natureza destes (Glassfish, Tomcat, JBoss, ...) utilizar um "grande" número de conexões e não reutilizá-las. Você pode ignorar com segurança, na maioria dos casos.