Let’s talk about nginx smooth restart and FPM smooth restart

This article will take you through smooth restart and introduce nginx smooth restart and FPM smooth restart in detail. I hope it can help you!

Smooth Restart

GR is the abbreviation of Graceful Restart (smooth restart), which is a method to ensure that forwarding services are not interrupted when the protocol is restarted. mechanism.
The core of the GR mechanism is that when a device restarts the protocol, it can notify its surrounding devices to maintain stable neighbor relationships and routes to the device within a certain period of time. After the protocol is restarted, peripheral devices assist it in synchronizing information (including various topology, routing and session information maintained by routing/MPLS-related protocols that support GR), restoring the device to the state before the restart in the shortest possible time. state. There will be no route flapping during the entire protocol restart process, and there will be no change in the packet forwarding path. The entire system can forward data without interruption. This process is called a smooth restart.

nginx smooth restart

The nginx process is divided into the master process and the worker process. The smooth restart of nginx is controlled by the signal HUB.

Note: On POSIX-compliant platforms, SIGUSR1 and SIGUSR2 are signals sent to a process that represent user-defined situations.

In order to analyze the smooth restart process of nginx in detail, we continue to monitor the nginx process changes.
Send HUP signal

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

##Through observation, a rough smooth restart can be analyzed The process is:

1. The master uses the new configuration to fork out n-1 workers and a new master
2. The new worker handles the new request, and the old worker exits after execution
3. The master reloads the configuration, during Use the new master to take over the service
4. After the master is loaded and configured, the new master switches to the worker working mode
After the smooth restart, the master process number will not change.

nginx smooth upgrade

HUP is only used for smooth restart, loading configuration, etc. If you want to smoothly upgrade the nginx version, reload the compiled binary file requires the help of the USR2 signal.

1. Send USR2 signal

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

##Observe the nginx process, fork out new master and worker, at this time The content of nginx.pid has changed, and the nginx.pid.oldbin file is generated in the logs directory to record the old master pid.

2. Send the WINCH signal to the old master, and nginx worker will stop the service gracefully. That is: stop receiving new requests, but will not terminate requests that are already being processed. After a period of time, all worker processes of the old nginx exit, leaving only the master process, and all user requests are processed by the new nginx process.

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

3. Send the QUIT signal to the old master, the old nginx process completely exits, and the smooth upgrade is completed.

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

FPM Smooth RestartFPM (FastCGI Process Manager) is used to replace PHP FastCGI Most of the additional functions, FPM has been integrated since php5.3.3. PHP-FPM can be turned on by passing the –enable-fpm parameter in ./configure.

FPM’s smooth restart needs to be controlled by the USR2 signal, but it is quite different from nginx’s smooth restart process.

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

By continuing to observe the fpm process, we can see that FPM restarts smoothly. It needs to wait for the child process to completely exit before starting the new master and child processes, and then the old master quit.

Use strace for further analysis

It is found that the master notifies all child processes to exit, including the child process that is processing the request.

In order to further verify this conclusion, write a server-side sleep script

<?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视频教程》

The above is the detailed content of Let’s talk about nginx smooth restart and FPM smooth restart. For more information, please follow other related articles on the PHP Chinese website!