Nginx 에서 reload 프로 세 스 의 진실 탐구

오늘 이 글 은 주로 Nginx 의 reload 절 차 를 소개 합 니 다.실제로 이전 글 에서 nginx 설정 파일 을 변경 할 때 저 희 는 nginx - s reload 명령 을 실행 합 니 다. 이 명령 을 실행 하 는 이 유 는 nginx 가 서 비 스 를 멈 추 지 않 고 새로운 요청 을 처리 하 는 동시에 nginx 설정 파일 을 부 드 럽 게 오래된 nginx. conf 설정 을 새로운 nginx. conf 설정 으로 업데이트 하 기 를 바 랍 니 다.
이러한 기능 은 nginx 에 매우 필요 합 니 다. 그러나 가끔 은 nginx -s reload 명령 을 실행 한 후에 worker 서브 프로 세 스 의 수량 이 많아 지 는 것 을 발견 할 수 있 습 니 다. 이것 은 오래된 설정 이 실 행 된 worker 프로 세 스 가 장시간 종료 되 지 않 았 기 때 문 입 니 다. stream 을 사용 하여 4 층 역방향 대 리 를 할 때 이런 장면 이 더 많 을 수 있 습 니 다.
그렇다면 다음은 nginx 의 reload 절 차 를 분석 함으로써 다음 nginx 가 무엇 을 했 는 지 살 펴 보 자.우아 한 탈퇴 와 즉각 탈퇴 는 어떤 차이 가 있 습 니까?
reload 프로 세 스
첫 번 째 단 계 는 nginx 설정 파일 nginx. conf 를 수정 한 후 master 프로 세 스에 HUP 신 호 를 보 냅 니 다. 이것 은 실제 명령 행 에서 실행 nginx -s reload 명령 효과 와 같 습 니 다.
그러면 master 프로 세 스 는 HUP 신 호 를 받 은 후에 두 번 째 단계 에서 우리 의 설정 파일 문법 이 정확 한 지 확인 합 니 다. 즉, 우 리 는 nginx - s reload 전에 nginx - t 를 실행 하지 않 아 도 문법 이 정확 한 지 확인 합 니 다. 두 번 째 단계 에서 nginx 의 master 프로 세 스 가 반드시 이 절 차 를 실행 할 것 이기 때 문 입 니 다.
nginx 의 설정 문법 이 모두 정확 한 후에 master 프로 세 스 는 새로운 감청 포트 를 열 것 입 니 다. 왜 master 프로 세 스 에서 새로운 감청 포트 를 열 어야 합 니까?nginx. conf 에 443 이나 이전에 열 리 지 않 았 던 감청 포트 를 추가 할 수 있 습 니 다. 모든 worker 프로 세 스 는 master 프로 세 스 의 하위 프로 세 스 입 니 다. 하위 프로 세 스 는 부모 프로 세 스 가 열 린 모든 포트 를 계승 합 니 다. 이것 은 Liux 운영 체제 가 정의 한 것 입 니 다. 세 번 째 단계 로 우리 master 프로 세 스 는 도입 가능 한 새로운 감청 포트 를 열 었 습 니 다.
다음 mster 프로 세 스 는 새로운 nginx. conf 프로필 로 새로운 worker 하위 프로 세 스 를 시작 합 니 다. 오래된 worker 하위 프로 세 스 는 어떻게 될까요?
저 희 는 다섯 번 째 단계 에서 새로운 worker 서브 프로 세 스 를 시작 한 후에 master 프로 세 스 에서 오래된 worker 서브 프로 세 스 에 QUIT 신 호 를 보 낼 것 입 니 다. QUIT 신호 와 TERM, INT 신 호 는 다 릅 니 다. QUIT 신 호 는 하위 프로 세 스 를 우아 하 게 닫 으 십시오. 이 럴 때 순 서 를 주목 해 야 합 니 다. nginx 는 부 드 러 움 을 확보 해 야 하기 때문에 새로운 worker 서브 프로 세 스 를 시작 해 야 합 니 다.오래된 워 커 서브 프로 세 스에 QUIT 신 호 를 보 냅 니 다.
그러면 오래된 master 서브 프로 세 스 가 QUIT 신 호 를 받 은 후에 먼저 감청 핸들 을 닫 습 니 다. 즉, 이 럴 때 새로운 연결 은 새로운 worker 서브 프로 세 스 만 도착 하기 때문에 시간 차 가 있 지만 시간 이 매우 빠 릅 니 다. 감청 핸들 을 닫 은 후에 현재 연결 을 처리 한 후에 프로 세 스 를 끝 냅 니 다.
새 설정 을 불 러 오 는 그림 을 보 려 면 reload 가 멈 추 지 않 습 니 다.
reload 멈 추 지 않 고 새 설정 불 러 오기
master 프로 세 스 에는 원래 네 개의 녹색 worker 서브 프로 세 스 가 있 었 습 니 다. 오래된 설정 을 사 용 했 습 니 다. ngix. conf 설정 파일 을 변경 한 후에 master 에 SIGHUP 신 호 를 보 내 거나 reload 명령 을 실행 한 다음 master 는 새로운 설정 파일 로 네 개의 노란색 worker 서브 프로 세 스 를 시작 합 니 다.이 때 는 네 개의 오래된 녹색 worker 서브 프로 세 스 와 네 개의 새로운 노란색 worker 서브 프로 세 스 가 병존 합 니 다.그러면 오래된 워 커 서브 프로 세 스 는 정상 적 인 상황 에서 이미 만들어 진 연결 요청 을 처리 한 후에 이 연결 을 닫 습 니 다. 이 연결 이 keeplive 요청 이라도 정상적으로 닫 습 니 다.
그러나 이상 한 상황 입 니 다. 일부 요청 에 문제 가 생 겨 클 라 이언 트 가 장시간 처리 할 수 없 으 면 이 요청 이 이 워 커 서브 프로 세 스 에 오래 머 물 게 됩 니 다. 그러면 이 워 커 서브 프로 세 스 는 장시간 존재 합 니 다. 새로운 연결 이 노란색 워 커 서브 프로 세 스 로 달 려 갔 기 때문에 영향 이 크 지 않 습 니 다.유일 하 게 영향 을 미 칠 수 있 는 것 은 녹색 worker 서브 프로 세 스 가 장시간 존재 하지만 이미 존재 하 는 연결 에 만 영향 을 주 고 새로운 연결 에 영향 을 주지 않 습 니 다.
우리 가 무슨 방법 으로 처리 할 수 있 습 니까?새 버 전에 서 새로운 설정 을 제공 합 니 다 workershutdown_timeout, 즉 가장 오래 기다 리 는 시간 입 니 다. 이렇게 master 프로 세 스 가 새로운 노란색 worker 프로 세 스 를 시작 한 후에 오래된 worker 프로 세 스 가 종료 되 지 않 으 면 시간 이 되면 오래된 worker 프로 세 스 를 강제로 종료 합 니 다.
총결산
본 고 는 주로 Nginx 가 새로운 프로필 을 부 드 럽 게 업그레이드 하 는 절 차 를 설명 하 였 으 며, 워 커 서브 프로 세 스 를 우아 하 게 닫 고 새로운 설정 을 시작 하 는 워 커 서브 프로 세 스 프로 세 스 간 의 관 계 를 알 게 된 후, 우 리 는 보기 드 문 이상 장면 을 더욱 잘 처리 할 수 있 습 니 다.