[Nginx 노트] 온라인 환경 에 대한 CLOSEWAIT 와 TIMEWAIT 너무 높 음
1716 단어 nginx
먼저 원인 을 분석 해 보 자, 문 제 는 쉽게 풀 렸 다.
우선 TIMEWAIT:
TIME 이해 해 주세요.WAIT 상태 가 발생 한 원인, 이 문 제 는 이미 많은 책 에 의 해 엉망 이 되 었 지만, 왜 많은 사람들 이 여전히 해결 하지 못 하 는 지, 그 원인 을 따 져 보면 역시
대부분 학술 파 입 니 다. 이런 문 제 를 실제로 만난 적 이 없습니다. 왜냐하면 TIMEWAIT 대량 생산 은 실제 응용 환경 에서 많이 발생 한다.
TIME_WAIT 가 발생 한 원인 은 역시 통신 과정 에서 서버 가 자발적으로 닫 혀 서 생 긴 것 이다. 서버 에서 마지막 FIN 패 키 지 를 보 낸 후에 시스템 은 Double 시간 을 기다린다.
의 MSL (Max Segment Lifetime) 은 클 라 이언 트 가 보 낸 FIN 을 기다 리 는 데 사 용 됩 니 다.ACK 와 FIN, 그 동안 서버 에 대응 하 는 socket 의 fd 는 다시 할 수 없습니다.
이용 할 수 있 습 니 다. 이렇게 하면 대량의 짧 은 연결 서비스 에서 TIME 가 나타 납 니 다.WAIT 과 다 현상.
해결 방안:
조정 TIMEWAIT 시간 초과
vi /etc/sysctl.conf
net.ipv4.tcp_tw_reuse = 1 。 TIME-WAIT sockets TCP , 0, ;
net.ipv4.tcp_tw_recycle = 1 TCP TIME-WAIT sockets , 0, 。
net.ipv4.tcp_fin_timeout = 20
그다음 은 CLOSEWAIT:
CLOSE_WAIT 가 발생 한 이 유 는 클 라 이언 트 가 자발적으로 닫 히 고 FIN 패 키 지 를 받 았 지만 응용 층 이 닫 기 동작 을 하지 않 아서 생 긴 것 이다.
CLOSE_WAIT 가 Nginx 위 에서 발생 한 원인 은 역시 Nagle 's 알고리즘 에 Nginx 자체 EPOLL 의 ET 트리거 모드 를 더 해서 생 긴 것 입 니 다.
ET 출발 모드 는 데이터 가 준비 되 었 을 때 리 셋 동작 을 실행 합 니 다. Nagle 's 알고리즘 은 TCP 패 키 지 를 누적 합 니 다. 마지막 패 킷 과
FIN 패키지 가 Nagle 's 알고리즘 에 합 쳐 져 EPOLL 의 ET 모드 가 한 번 만 출발 하지만 응용 층 의 SOCKET 은 읽 기 되 돌려 줍 니 다.
0 이 야 말로 링크 가 닫 힌 것 을 의미 합 니 다. 이번 합 병 된 패 킷 을 읽 을 때 0 으로 돌아 가지 않 습 니 다. 그리고 SOCKET 이후 에는 이벤트 가 발생 하지 않 습 니 다. 따라서
응용 층 이 SOCKET 를 닫 지 않 아 대량의 CLOSE 가 발생 합 니 다.WAIT 상태 링크.
TCP 닫 기NODELAY, Nginx 설정 에 추가
tcp_nodelay on;
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
간단! Certbot을 사용하여 웹 사이트를 SSL(HTTPS)화하는 방법초보자가 인프라 주위를 정돈하는 것은 매우 어렵습니다. 이번은 사이트를 간단하게 SSL화(HTTP에서 HTTPS통신)로 변경하는 방법을 소개합니다! 이번에는 소프트웨어 시스템 Nginx CentOS7 의 환경에서 S...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.