nginx 부드러운 재시작과 FPM 부드러운 재시작이란 무엇입니까?

Graceful Restart

GR은 Graceful Restart의 약자로, 프로토콜이 다시 시작될 때 전달 서비스가 중단되지 않도록 하는 메커니즘입니다.
GR 메커니즘의 핵심은 장치가 프로토콜을 다시 시작할 때 안정적인 이웃 관계를 유지하도록 주변 장치에 알리고 특정 시간 내에 해당 장치로 경로를 지정할 수 있다는 것입니다. 프로토콜이 다시 시작된 후 주변 장치는 정보(GR을 지원하는 라우팅/MPLS 관련 프로토콜에서 유지 관리하는 다양한 토폴로지, 라우팅 및 세션 정보 포함)를 동기화하도록 지원하여 장치가 다시 시작되기 전 상태로 복원될 수 있도록 합니다. 가능한 한 짧은 상태. 전체 프로토콜 재시작 프로세스 동안 경로 플래핑이 발생하지 않으며, 패킷 전달 경로에 변경이 없으며 전체 시스템이 중단 없이 데이터를 전달할 수 있습니다. 이 프로세스를 원활한 다시 시작이라고 합니다.

nginx 원활한 재시작

Nginx 프로세스는 메인 프로세스와 작업자 프로세스의 두 가지 유형으로 나눌 수 있습니다. 원활한 재시작은 신호 허브를 통해 제어됩니다.

참고: POSIX 호환 플랫폼에서 SIGUSR1 및 SIGUSR2는 사용자 정의 상황을 나타내는 프로세스로 전송되는 신호입니다.

nginx의 원활한 재시작 프로세스를 자세히 분석하기 위해 nginx 프로세스 변경 사항을 지속적으로 모니터링하고 있습니다.
HUP 신호 보내기

kill -HUP `cat /home/git/nginx/logs/nginx.pid`

관찰을 통해 대략적인 원활한 재시작 프로세스를 다음과 같이 분석할 수 있습니다.
1 마스터는 새 구성을 사용하여 n-1 작업자와 새 마스터를 분기합니다
2. 신규 작업자가 새 요청을 처리하고 이전 작업자는 실행 후 종료됩니다
3. 마스터는 구성을 다시 로드하고, 이 동안 새 마스터는 서비스를 인계받습니다
4. 마스터가 작업자 작업 모드로 전환됩니다
원활한 재시작 후 마스터 프로세스 번호가 변경됩니다.

nginx 원활한 업그레이드

HUP는 원활한 재시작, 구성 로딩 등에 대해서만 사용됩니다. nginx 버전을 원활하게 업그레이드하고 컴파일된 바이너리 파일을 다시 로드하려면 USR2 신호를 사용해야 합니다.

1. USR2 신호 보내기

kill -USR2 `cat /home/git/nginx/logs/nginx.pid`

nginx 프로세스를 관찰하고, 새 마스터와 워커를 포크합니다. 이때 nginx.pid의 내용이 변경되고 nginx.pid.oldbin이 생성됩니다. 로그 디렉터리 파일에 이전 마스터 pid를 기록합니다.

2. 이전 마스터에 WINCH 신호를 보내면 nginx 작업자가 서비스를 정상적으로 중지합니다. 즉, 새 요청 수신을 중지하지만 이미 진행 중인 요청은 종료하지 않습니다. 처리됨. 일정 시간이 지나면 이전 nginx의 모든 작업자 프로세스가 종료되고 마스터 프로세스만 남게 되며 모든 사용자 요청은 새로운 nginx 프로세스에 의해 처리됩니다.

kill -WINCH `cat /home/git/nginx/logs/nginx.pid.oldbin`

3. 이전 마스터에 QUIT 신호를 보내면 이전 nginx 프로세스가 완전히 종료되고 원활한 업그레이드가 완료됩니다.

kill -QUIT `cat /home/git/nginx/logs/nginx.pid.oldbin`

FPM Smooth Restart

FPM(FastCGI Process Manager)은 php5.3.3 이후에 PHP FastCGI의 추가 기능 대부분을 대체하는 데 사용됩니다. PHP-FPM을 활성화하는 매개변수입니다.

FPM의 원활한 재시작은 USR2 신호에 의해 제어되어야 하지만 nginx의 원활한 재시작 프로세스와는 상당히 다릅니다.

kill -USR2 `cat /home/git/php/var/run/php-fpm.pid`

fpm 프로세스를 계속 관찰하면 FPM이 원활하게 다시 시작되는 것을 볼 수 있습니다. 새 마스터 및 하위 프로세스를 시작하기 전에 하위 프로세스가 완전히 종료될 때까지 기다려야 하며 그런 다음 이전 마스터가 종료됩니다.
추가 분석을 위해 strace 사용

마스터가 요청을 처리 중인 하위 프로세스를 포함하여 모든 하위 프로세스를 종료하라고 알린 것으로 나타났습니다.

이 결론을 더욱 검증하기 위해 서버 측 절전 스크립트를 작성하세요

<?php
exec("sleep 5");
echo &#39;done&#39;;

브라우저를 사용하여 이 주소를 요청하면 이 기간 동안 fpm이 원활하게 다시 시작되며 요청은 직접 502가 됩니다.
nginx 오류 로그:

[error] 29841#0: *1646 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1, server: localhost, request: "GET /test.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9001", host: "localhost"

php bug#60961, fpm이 원활하게 다시 시작할 수 없는 이유도 설명합니다.
FPM이 그렇게 낮나요? 당시에는 '아니오'였습니다. 실제로 우리의 목표는 process_control_timeout 매개변수를 통해 달성할 수 있습니다.

process_control_timeout

하위 프로세스가 기본 프로세스의 재사용 신호를 수락하도록 시간 초과를 설정합니다. 사용 가능한 단위: s(초), m(분), h(시간) 또는 d(일). 기본 단위: s(초). 기본값: 0(끄기).

원칙적으로 php-fpm은 요청을 처리하기 위해 유휴 fastcgi 프로세스를 선택합니다. php-fpm은 요청 처리를 수락하기 위한 fastcgi 프로세스를 준비하기 위해 fastcgi에 신호를 보냅니다. 그러나 fastcgi 프로세스는 항상 요청을 처리할 수 있는 것은 아닙니다. 즉, 신호(예: 정지된 애니메이션)에 항상 응답할 수는 없습니다. 이때 php-fpm이 fastcgi 프로세스를 위해 남겨두는 시간을 설정해야 합니다. 시간이 초과되면 php -fpm은 다른 방법(예: 다른 fastcgi 프로세스 선택)을 생각할 것입니다. 이것이 process_control_timeout 매개변수의 역할입니다.

이 매개변수의 기본값은 0이며, 이는 적용되지 않음을 의미합니다. 10으로 변경하고 502가 더 이상 나타나지 않습니다.

위 내용은 nginx 부드러운 재시작과 FPM 부드러운 재시작이란 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!