트래픽이 많은 웹 서비스를 운영하면, CPU 자체는 여유가 있지만 Web Server 및 WAS가 응답을 제대로 처리하지 못하고 처리 시간이 지연되는 현상을 확인할 수 있다. 이 중 CLOSE_WAIT가 과다하게 걸려서 생기는 현상에 의한 것에 대한 발생 원인 및 해결책에 대한 글이다.
일단 CLOSE_
WAIT을 알기 전에 TCP/IP 통신에 대한 공부가 필요하다.
close되는 상태를 확인하자면 우선 Initiator에서 FIN_WAIT_1 에서 close()를 수행하고, Receiver는 ACK를 보낸 이후 어플리케이션에 close()를 수행한다.
(완벽하게 이해는 하지 못했지만, 이에 대해서는 다음 기회에 추가적으로 상세히 공부하는 시간을 갖도록 하겠다.)
다만 CLOSE_WAIT가 생기는 이유는 close가 되지 못한 thread가 wait을 하고 있기 때문이다.
TCP 연결은 원격 시스템에서 FIN을 받은 후 로컬 응용 프로그램에서 닫기가 호출되기 전에 ESTABLISHED 상태에서 CLOSE_WAIT 상태로 이동한다.
CLOSE_WAIT에 대한 보다 자세한 분석을 위해서는 다음과 같은 옵션들을 사용할 수가 있다.
# truss -o truss.out -laef -vall -p <서버 프로세스의 pid>
# snoop -o snoop.out 포트 <tcp 포트 번호>
위 응용 프로그램이 TCP connection에서 CLOSE가 실행되지 않은 것에는 다음과 같은 원인들이 있을 수 있다.
1. 응용 프로그램이 연결에 대한 데이터 전송을 완료하지 못했을 때.
2. 응용 프로그램이 CLOSE에 대한 알림을 받지 못했을 때 (응용 프로그램이 socket을 읽지 않으면 다른 쪽에서 close된 것을 모른다.)
3. 미들웨어 case
=> 일부 미들웨어 서버에는 서버가 TCP 연결을 수락한 다음 연결을 처리하도록 자식을 분기하지만 분기가 실행되기 전에 다른 스레드가 다른 TCP 연결을 수락하는 버그가 있습니다. 따라서 두 개의 자식 프로세스가 있지만 둘 모두에 하나의 소켓이 복사됩니다. 두 프로세스가 모두 종료될 때까지 이 소켓을 닫을 수 없습니다. 소켓을 잘못 가지고 있는 프로세스가 특히 오래 지속되는 경우 소켓이 있어야 하는 자식은 수명이 짧지만 오래 지속되는 프로세스가 종료될 때까지 소켓은 CLOSE_WAIT 상태로 종료됩니다. (Oracle Support 문서에서 확인)
===========================
<<테스트 환경 구축 시도>>
현재 8080 포트를 사용하는 Web Server에서는 크게 어플리케이션을 사용하지 않는 테스트 구성이기에 확인하다시피 크게 많은 서비스들이 해당 포트로 사용되지 않고 있다.
하지만 트래픽이 많은 서버의 경우 이 숫자가 몇천개, 몇만개로 올라갈 수도 있다.
===========================
<<CLOSE_WAIT 분석 및 해결 방법에 대한 고찰>>
CLOSE_WAIT은 포트를 잡고 있는 프로세스의 종료 또는 네트워크 재시작 외에는 제거할 방법이 없다.
즉 로컬 어플리케이션이 정상적으로 close()를 요청하는 것이 가장 좋은 방법이다.
다만 운영중인 서비스(특히 JAVA 기반의 웹 서비스)에서 어떠한 부분이 CLOSE_WAIT을 야기시키는지 보다 자세히 분석하기 위해서는 JVM의 Thread Dumps를 분석할 수 있다.
# jstack {java PID}
=> thread 상태가 WAITING이나 DEADLOCK 상태 등등에 있다면, 해당 thread dump에 대한 보다 자세한 분석을 진행할 수 있다.
(참고: https://tech.kakao.com/2016/04/21/closewait-timewait/#close_wait-%EC%A2%85%EB%A3%8C)
'Linux & Windows' 카테고리의 다른 글
$'\r': command not found (0) | 2023.01.13 |
---|---|
User 계정으로 권한 있는 파일 찾아내서 지우기 (0) | 2022.11.02 |
profile & Library Path (0) | 2022.08.31 |
Linux entropy (0) | 2022.08.18 |
nohup background (0) | 2022.07.01 |