H11. 서버 소켓 과다 진단
Diátaxis: How-to(목표별 가이드) · 대상: 운영자 / 관리자 ← 목차로
"새 연결이 간헐적으로 거부된다", "트래픽은 평소 수준인데 접속이 늘어진다"면 TCP 소켓이 한쪽 상태에 쌓여 포트나 연결 자원이 마른 경우를 의심합니다. 이 문서는 서버 ▸ 네트워크의 TCP 연결상태 차트로 소켓 분포를 읽고, 어느 쪽이 문제인지 가려 대응하는 순서입니다.
시스템 차트의 항목별 임계치는 R2.4 시스템(서버) 차트 — 네트워크에 있습니다. CPU·디스크 포화는 H10. CPU·디스크 임계 초과 대응을 보세요.
여는 법 — 소켓 분포는 두 곳에서 볼 수 있고, 보는 범위가 다릅니다(아래 "두 곳에서 보기" 참고).
- 호스트(OS) 전체 — 좌측 메뉴 ▸ 서버 ▸ (호스트 선택) ▸ 네트워크 탭 ▸ TCP 연결상태
- 그 WAS(JVM) 프로세스만 — 좌측 메뉴 ▸ WAS ▸ (인스턴스 선택) ▸ 트러블슈팅 ▸ 네트워크 상태 분석
TCP 연결 상태 분포 읽기
TCP 연결상태 차트는 소켓을 상태별(ESTABLISHED · TIME_WAIT · CLOSE_WAIT · FIN_WAIT 등)로 나눠 보여 줍니다. 어느 상태가 비정상적으로 많은가가 원인을 가립니다.
위 화면에 두 문제가 함께 보입니다 — TIME_WAIT(청록)는 트래픽이 몰린 구간에 봉우리처럼 급증했다가 서서히 빠집니다(짧은 연결 폭주 → 포트 고갈). CLOSE_WAIT(보라)는 계단처럼 우상향한 뒤 내려오지 않습니다(닫지 않은 소켓이 쌓이는 누수). 같은 차트라도 모양이 다르면 원인이 다릅니다.
| 많은 상태 | 의미 · 다음 점검 |
|---|---|
| ESTABLISHED | 실제 활성 연결. 트래픽에 비례하면 정상. 급증하면 연결 폭주·Keep-Alive 과다 |
| TIME_WAIT | 연결을 정상 종료한 쪽에 잠깐(보통 60초) 남는 상태. 높은 트래픽 뒤 대량이면 로컬 포트 고갈 위험 |
| CLOSE_WAIT | 상대가 끊었는데 내 애플리케이션이 close()를 안 한 상태. 줄지 않고 쌓이면 커넥션 누수(코드 결함) |
| FIN_WAIT1 / FIN_WAIT2 | 종료 절차 진행 중. 다량이 오래 머물면 상대 응답 지연·방화벽이 중간에서 끊는 상황 의심 |
핵심 TIME_WAIT 과 CLOSE_WAIT 는 원인이 정반대입니다.
- TIME_WAIT 多 = 연결을 많이 맺고 빨리 끊는 패 턴(짧은 커넥션 폭주). 자원 누수가 아니라 연결 재사용이 안 되는 구조 문제입니다.
- CLOSE_WAIT 多 = 받은 연결을 닫지 않고 붙잡고 있는 패턴. 시간이 지나도 줄지 않으면 거의 항상 애플리케이션 코드의
close()누락입니다.
호스트 전체인가, 그 JVM 프로세스인가 — 두 곳에서 보기
같은 TCP 연결 상태를 두 화면에서 볼 수 있는데, 보는 범위가 다릅니다.
| 화면 | 보는 범위 | 언제 쓰나 |
|---|---|---|
| 서버 ▸ 네트워크 ▸ TCP 연결상태 | 그 호스트(OS) 전체의 소켓 | "이 서버 전체가 포트 고갈인가" |
| WAS ▸ 트러블슈팅 ▸ 네트워크 상태 분석 | 그 WAS 인스턴스(JVM 프로세스, PID) 하나의 소켓 | "이 누수가 이 WAS 때문인가" |
- 서버 네트워크는 OS 전체를 봅니다. 한 호스트에 WAS·웹서버·배치가 함께 떠 있으면 그 모두의 소켓이 합산되므로, 어느 프로세스 탓인지는 알 수 없습니다.
- WAS 트러블슈팅 ▸ 네트워크 상태 분석은 그 WAS의 JVM 프로세스(PID) 하나가 연 소켓만
netstat으로 떠서 상태별로 보여 줍니다. 그 인스턴스만 떼어 보므로 출처가 분명합니다.
핵심 호스트 전체(서버 네트워크)에서 TIME_WAIT·CLOSE_WAIT 가 많이 보일 때, 그게 어느 프로세스 탓인지는 JVM 단위(WAS 트러블슈팅 ▸ 네트워크 상태 분석)로 좁혀야 가려집니다. 그 WAS의 PID 소켓만 떼어 같은 상태가 쌓여 있으면, 누수의 출처가 그 인스턴스임이 확정됩니다.
TIME_WAIT 과다 — 포트 고갈 진단
TIME_WAIT 는 정상 종료의 흔적이라 있는 것 자체는 정상입니다. 문제는 수입니다.
- 판별 — 높은 트래픽(또는 짧은 커넥션 대량 생성) 직후 TIME_WAIT 가 수만 개로 치솟고,
새 연결이
Cannot assign requested address(포트 고갈)로 실패하면 TIME_WAIT 포화입니다. - 보통 외부로 짧은 HTTP/DB 연결을 매번 새로 맺는 클라이언트(배치·크롤러·연동 모듈)가 원인입니다.
- 확정 — 같은 시간대 R2.2 웹서버 차트 연결 상태, WAS 트랜잭션의 외부 호출 빈도와 겹쳐 봅니다.
CLOSE_WAIT·FIN_WAIT 누적 — 커넥션 누수 진단
CLOSE_WAIT 가 트래픽이 줄어든 뒤에도 내려오지 않으면 누수입니다.
- 판별법 — H2. 기간 바꿔 보기로 추세를 펼쳐, CLOSE_WAIT 가 계단처럼 우상향하는지 봅니다. 한 번 올라간 뒤 안 내려오면 닫지 않은 소켓이 쌓이는 것입니다.
- FIN_WAIT2 가 다량으로 오래 머물면, 상대(백엔드·외부 API)가 종료에 응답하지 않거나 중간 방화벽이 유휴 연결을 끊어 한쪽만 닫힌 상태일 수 있습니다.
- 누수는 JVM 쪽 자원도 함께 마르게 합니다 — 소켓 하나가 파일 디스크립터 하나이므로, H12. JVM 열린 파일 디스크립터 고갈 진단을 함께 확인하세요.
조치
| 확인된 상황 | 1차 조치 |
|---|---|
| TIME_WAIT 과다(포트 고갈) | 짧은 연결을 재사용으로 — HTTP Keep-Alive·DB/HTTP 커넥션 풀 적용. OS 임시포트 범위·tcp_tw_reuse 등은 인프라팀과 검토 |
| CLOSE_WAIT 누수 | 받은 연결을 닫지 않는 코드 점검(close()/try-with-resources 누락) — 개발팀 전달. 근본 원인이라 재시작은 임시방편 |
| FIN_WAIT2 다량 | 상대 백엔드·외부 API 종료 응답, 중간 방화벽 유휴 타임아웃 점검 |
| 급한 불 | 트래픽 분산 후 해당 인스턴스 순차 재시작으로 소켓 자원 우선 회복 |
주의 TIME_WAIT 를 OS 파라미터로 무리하게 줄이면 늦게 도착한 패킷이 새 연결에 섞이는 위험이 있습니다. 연결 재사용(풀·Keep-Alive) 이 정석이고, OS 튜닝은 인프라팀과 함께 신중히 합니다.
잘 안될 때
| 증상 | 점검 |
|---|---|
| 네트워크 탭에 데이터 없음 | 호스트의 시스템 에이전트 연결 상태 — H20. 에이전트 점검 |
| 소켓은 정상인데 접속이 느림 | 소켓 문제 아님 — CPU·디스크(H10)·WAS 스레드 풀 먼저 확인 |
| 어느 프로세스의 소켓인지 모름 | WAS ▸ 트러블슈팅 ▸ 네트워크 상태 분석으로 그 JVM(PID) 소켓만 떼어 확인 (위 "두 곳에서 보기") |
관련 문서
- R2.4 시스템(서버) 차트 — 네트워크 · R2.2 웹서버 차트
- H12. JVM 열린 파일 디스크립터 고갈 진단 — 소켓 누수가 FD 고갈로 번질 때
- H10. CPU·디스크 임계 초과 대응 · H20. 에이전트 상태 점검
- H14. AI로 차트·이벤트 분석 받기