nginx 부드러운 다시 시작 및 FPM 부드러운 다시 시작에 대해 이야기해 보겠습니다.

이 글에서는 원활한 재시작 과정을 안내하고 nginx 부드러운 재시작 및 FPM 부드러운 재시작을 자세히 소개하겠습니다. 도움이 되기를 바랍니다.

Graceful Restart

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

nginx 원활한 재시작

nginx 프로세스는 마스터 메인 프로세스와 작업자 프로세스로 구분됩니다. nginx의 원활한 재시작은 신호 허브에 의해 제어됩니다.

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

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

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

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

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의 추가 기능 대부분을 대체하는 데 사용됩니다. -fpm 매개변수는 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这么low？答案当时是no，实际上通过 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已经不会再出现。

 结论：缺省情况下，PHP-FPM 无法保证平滑的执行 reload 操作，必须设置一个合理的 process_control_timeout 才行，同时需要注意的是其值不能设置的过大，否则系统可能出现严重的请求堵塞问题。

推荐学习：《PHP视频教程》

위 내용은 nginx 부드러운 다시 시작 및 FPM 부드러운 다시 시작에 대해 이야기해 보겠습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!