rhel 시스템에서 다음 cli를 실행하면 600개 이상의 CLOSE_WAIT
라인이 표시됩니다.
lsof -i tcp:8088 | grep CLOSE_WAIT
java 31100 yarn 385u IPv4 208022048 0t0 TCP master02.hgti.com:radan-http->master02.hgti.com:56504 (CLOSE_WAIT)
java 31100 yarn 407u IPv4 208210692 0t0 TCP master02.hgti.com:radan-http->master02.hgti.com:58918 (CLOSE_WAIT)
java 31100 yarn 408u IPv4 206182798 0t0 TCP master02.hgti.com:radan-http->master02.hgti.com:36538 (CLOSE_WAIT)
java 31100 yarn 410u IPv4 208447279 0t0 TCP master02.hgti.com:radan-http->master02.hgti.com:60972 (CLOSE_WAIT)
java 31100 yarn 412u IPv4 208287324 0t0 TCP master02.hgti.com:radan-http->master02.hgti.com:59820 (CLOSE_WAIT)
java 31100 yarn 413u IPv4 206107964 0t0 TCP master02.hgti.com:radan-http->master02.hgti.com:35704 (CLOSE_WAIT)
.
.
.
.
.
제가 아는 한, 서버와 클라이언트 사이의 통신 과정에서 closed_wait
서버의 소켓 장애로 인한 상황이 발생하게 됩니다.
그렇다면 Linux 측에서 일부 설정을 수행할 기회가 있습니까? 세션을 최소화하려면 close wait
?
아니면 애플리케이션 측면의 유일한 솔루션이어야 할까요?
답변1
나는 이것이 응용 프로그램의 버그일 수 있다고 생각합니다. 열려 있는 파일/소켓의 최대 수를 소진하기 전에 응용 프로그램을 다시 시작하거나 인위적인 한계 ulimit 설정을 늘리면 이를 제어할 수 있습니다.
다음과 같은 버그 보고서를 찾아보세요.
- https://issues.apache.org/jira/browse/YARN-9336
- https://issues.apache.org/jira/browse/YARN-4754
- https://issues.apache.org/jira/browse/YARN-10207
또는 직접 신고하십시오(지원서인 경우). 이러한 문제에 대한 논의는 다음을 참조하세요.https://stackoverflow.com/questions/15912370/how-do-i-remove-a-close-wait-socket-connection