rhel + Linux 측에서 CLOSE_WAIT 세션을 최소화하기 위한 모범 사례

rhel + Linux 측에서 CLOSE_WAIT 세션을 최소화하기 위한 모범 사례

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?

아니면 애플리케이션 측면의 유일한 솔루션이어야 할까요?

인용하다 -https://www.programmerought.com/article/74221875444/

답변1

나는 이것이 응용 프로그램의 버그일 수 있다고 생각합니다. 열려 있는 파일/소켓의 최대 수를 소진하기 전에 응용 프로그램을 다시 시작하거나 인위적인 한계 ulimit 설정을 늘리면 이를 제어할 수 있습니다.

다음과 같은 버그 보고서를 찾아보세요.

또는 직접 신고하십시오(지원서인 경우). 이러한 문제에 대한 논의는 다음을 참조하세요.https://stackoverflow.com/questions/15912370/how-do-i-remove-a-close-wait-socket-connection

관련 정보