☰

CLOSE_WAIT 상태에서 분리된 연결

tag-icon • tag-icon linux networking tcp
CLOSE_WAIT 상태에서 분리된 연결

CLOSE_WAIT 상태에서 TCP 연결을 누적하고 결코 발생하지 않는 SLES 시스템이 있습니다. 이러한 설명자는 결국 사용 가능한 모든 메모리를 소모합니다. 현재 3037이 있는데 최근 급하게 재부팅하기 전에는 그 숫자가 훨씬 더 많았습니다.

흥미롭게도 이러한 신호는 청취 프로세스가 예상되는 로컬 포트에 대한 연결에서 발생하지 않습니다. 연관된 PID가 없으며 타이머가 만료된 것으로 보입니다.

# netstat -ton | grep CLOSE_WAIT
tcp      176      0 10.0.0.60:54882     10.0.0.12:31663      CLOSE_WAIT  off (0.00/0/0)
tcp       54      0 10.0.0.60:60957     10.0.0.12:4503       CLOSE_WAIT  off (0.00/0/0)
tcp       89      0 10.0.0.60:50959     10.0.0.12:3518       CLOSE_WAIT  off (0.00/0/0)

# netstat -tonp | grep CLOSE_WAIT
tcp       89      0 10.0.0.59:45598     10.0.0.12:1998       CLOSE_WAIT  -                   
tcp       15      0 10.0.0.59:60861     10.0.0.12:1938       CLOSE_WAIT  -                   
tcp        5      0 10.0.0.59:56173     10.0.0.12:1700       CLOSE_WAIT  -

나는 TCP 스택이나 커널 네트워킹에 관해서는 블랙 벨트가 아니지만 매뉴얼 페이지에 따르면 다음 값이 기본값이므로 TCP 구성은 괜찮아 보입니다.

# cat /proc/sys/net/ipv4/tcp_fin_timeout 
60
# cat /proc/sys/net/ipv4/tcp_keepalive_time 
7200

그러면 무엇이 주어지나요? 타이머가 만료되면 스택이 이러한 항목을 자동으로 지워야 하지 않나요? 이런 일들이 쌓이면서 실제로는 장기간의 서비스 거부를 겪었습니다.

답변1

아니요, 시간 초과가 없습니다 CLOSE_WAIT. 나는 이것이 off당신의 결과가 의미하는 바라고 생각합니다.

를 종료하려면 CLOSE_WAIT애플리케이션이 명시적으로 소켓을 닫거나 종료해야 합니다.

바라보다CLOSE_WAIT를 중단하는 방법.

netstat프로세스 표시줄에 표시된 경우 :-

  • 적절한 권한과 기능(예: 루트로)을 사용하여 실행하고 있습니까?
  • 커널 프로세스(예: nfsd)일 수 있습니다.

답변2

CLOSE_WAIT클라이언트가 연결을 닫고 있지만 애플리케이션이 연결을 닫지 않았거나 클라이언트가 아직 닫지 않았음을 나타냅니다. 어떤 프로그램에 이 문제가 있는지 확인해야 합니다. 사용해 보세요

netstat -tonp 2>&1 | grep CLOSE

어떤 프로그램이 계속 연결되어 있는지 확인합니다.

프로그램이 나열되지 않으면 서비스는 커널에서 제공됩니다. 이는 nfs또는 와 같은 RPC 서비스일 수 있습니다 rpc.lockd. 청취 커널 서비스를 나열할 수 있습니다.

netstat -lntp 2>&1 | grep -- -

RPC 서비스가 고정 포트에 바인딩되지 않은 경우 연결에 표시된 임시 포트에 바인딩됩니다. 다른 서버의 프로세스와 설치를 확인할 수도 있습니다.

다음을 수행하여 NFS 서비스를 고정 포트에 바인딩할 수 있습니다.

  1. 사용되지 않은 NFS 포트 4개를 선택합니다(여기에서는 32763-32766이 사용됨).
  2. NFS용 고정 포트 추가/etc/services 
    rpc.statd-bc 32763/udp # RCP statd 브로드캐스트
rpc.statd-bc 32763/tcp
rpc.statd 32764/udp # RCP statd 모니터링
rpc.statd 32764/tcp
rpc.mountd 32765/udp # RPC 마운트
rpc.mountd 32765/tcp
rpc.lockd 32766/udp # RPC 잠금/nlockmgr
rpc.lockd 32766/tcp
  3. 옵션을 사용하도록 statd 구성--port 32763 --outgoing-port 32764
  4. 이 옵션을 사용하려면 rpcmountd를 구성하세요.--port 32765
  5. NFS 및 RPC 서비스를 종료하고 다시 시작합니다.

답변3

하지만미켈의 답변NFS와 같은 커널 측 소켓이 이 문제를 일으킬 수 있다는 것도 사실일 수 있습니다. CLOSE_WAIT -연관된 FD가 없는 항목이 더 일반적입니다.

listen()로컬 대기열에 있는 동안 상대방이 이전에 닫은 연결을 accept()호출할 수 있습니다.나의 자세한 답변과 재현은 여기에 있습니다.

CLOSE_WAIT 상태에서는 영원히 지속될 것 같습니다.

그들은 당신이 나올 때까지 영원히 그 상태로 있을 것입니다

  • accept()그 다음에는 close()그들, 또는
  • close()전체 소켓(해결책이 아닐 수도 있음)

이 글에도 자세히 설명되어 있습니다링크 답변.

이러한 설명자는 결국 사용 가능한 모든 메모리를 소모합니다.

man 2 listen대기열의 길이는 다음에 따라 listen()제한되므로 이런 일이 발생해서는 안 됩니다.

/proc/sys/net/ipv4/tcp_max_syn_backlog  # default 4096
/proc/sys/net/core/somaxconn            # default 4096

물론 여러 개의 소켓이 있는 경우를 제외하고 listen()위의 제한은 각 소켓에 대한 것입니다.

관련 정보