Java 애플리케이션 서버(GlassFish)에 대한 역방향 프록시로 Apache를 설정했으며 유휴 개발 시스템에서도 CLOSE_WAIT 상태에 약 100개의 연결이 있음을 확인했습니다.
sudo netstat -n -e -p -a -t | grep httpd | grep CLOSE_WAIT | wc -l
다음 HTTP 프록시 설정을 사용하고 있습니다.
ProxyPass /myapp http://localhost:8080/myapp ttl=20 max=1 smax=0
ProxyPassReverse /myapp http://localhost:8080/myapp
왜 이 모든 연결이 계속 유지되고 있습니까? 나는 "ttl=20 max=1 smax=0"을 설정하여 유휴 시스템에서 모든 연결이 정리될 것이라고 생각했습니다. 애플리케이션 서버가 연결을 정리하는 역할을 수행하지 않습니까?
답변1
이것은mod_proxy의 알려진 문제, 2011년부터.
ttl은 애플리케이션의 keepalive보다 짧아야 아파치가 항상 FIN을 가장 먼저 보낼 수 있습니다.
또 다른 어려움은 연결이 실제로 닫히는 지점이 정의되어 있지 않다는 것입니다.
ttl - 비활성 연결 및 관련 연결 풀 항목의 수명(초)입니다. 이 제한에 도달하면 연결이 다시 사용되지 않습니다. 에 문을 닫을 거예요나중에 좀.
답변2
비슷한 문제가 발생하여 Apache와 관련된 추론을 찾고 있습니다. 나는 Apache의 프리포크를 의심합니다.
해결책으로는 CLOSE_WAIT 문제를 해결한 Nginx를 사용했습니다. 그러나 TIME_WAIT의 수(약 20,000)는 Java 애플리케이션이 연결을 처리하는 방식에 문제가 있음을 나타냅니다. Nginx 서버와 애플리케이션을 사용하면 훨씬 더 나은 성능을 발휘합니다.
누군가가 기술적인 깊이로 이 답변을 개선할 수 있기를 바랍니다.
답변3
이러한 CLOSE_WAIT 연결은 끊어졌습니다. 추가 패킷이 도착할 경우를 대비해 TCP 스택에 연결을 유지하는 것은 서버뿐입니다. "옛날"에는 파일 설명자가 너무 크면 Solaris 서버에 파일 설명자가 부족해졌고 시스템이 충돌했습니다. 커널에 허용되는 총 파일 설명자 수를 늘리고 CLOSE_WAIT 연결의 정리 간격을 줄여야 했습니다.
요즘에는 기본 파일 설명자 수는 일반적으로 이를 무시할 만큼 충분히 큽니다. 하지만 정리 구성을 줄일 수 있으므로 CLOSE_WAIT 연결 수가 줄어듭니다.
이러한 유형(Glassfish, Tomcat, JBoss 등)의 특성상 "많은" 수의 연결을 사용하고 이를 재사용하지 않는 것입니다. 대부분의 경우 무시해도 됩니다.