What are nginx smooth restart and FPM smooth restart?

Smooth Restart

GR is the abbreviation of Graceful Restart. It is a mechanism to ensure that forwarding services are not interrupted when the protocol is restarted.
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 can be divided into two types: the main process and the worker process. Its smooth restart is controlled through 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 and reload the compiled binary file, you need to use 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 Restart

FPM (FastCGI Process Manager) is used to replace most of the additional functions of PHP FastCGI, php5 FPM has been integrated since .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;;

Use the browser to request this address, and during this period, fpm will be restarted smoothly, and the request will be directly 502.

nginx error log:

[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, there is also a description of fpm's inability to gracefully achieve a smooth restart. Is FPM so low? The answer was no at that time, in fact our goal can be achieved through the process_control_timeout parameter.

process_control_timeout

<p>Set the timeout for the child process to accept multiplexing signals from the main process. Available units: s (seconds), m (minutes), h (hours) or d (days). Default unit: s (seconds). Default: 0 (off). </p> <p>In principle, php-fpm will select an idle fastcgi process to process the request. Before processing, php-fpm will send a signal to fastcgi to prepare the fastcgi process to accept the request processing. However, the fastcgi process is not always able to handle the request, that is, it cannot always respond to the signal (such as suspended animation). At this time, you need to set the time php-fpm leaves for the fastcgi process to respond to the signal. If it times out, php -fpm will think of other ways (such as selecting other fastcgi processes), this is the role of the process_control_timeout parameter. </p> <p>The default value of this parameter is 0, which means it does not take effect. Change it to 10 and re-verify. 502 will no longer appear. </p>

The above is the detailed content of What are nginx smooth restart and FPM smooth restart?. For more information, please follow other related articles on the PHP Chinese website!