What are nginx smooth restart and FPM smooth restart?

Smooth restart

GR is short for Graceful Restart, which is a mechanism to ensure uninterrupted forwarding service when the protocol is restarted. The core of GR mechanism is that when a device restarts the protocol, it can inform its peripheral devices to keep the neighbor relationship and routing to the device stable for a certain period of time. After the protocol is restarted, the peripheral equipment will assist it to synchronize information (including various topologies, routes and session information maintained by GR-supporting routing /MPLS related protocols), so as to restore the equipment to the state before the restart in the shortest possible time. During the whole protocol restart process, there will be no routing oscillation, and the message forwarding path will not change, so the whole system can forward data continuously. This process is called a smooth restart.

Nginx smooth restart

Nginx process can be divided into main process and working process, and its smooth restart is controlled by signal HUB.

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

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

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

Through observation, it can be analyzed that the approximate smooth restart process is as follows: 1. master uses the new configuration fork to generate n-1 workers and a new master; 2. The new worker handles the new request, and the old worker exits after execution; 3. master reloads the configuration, during which the new master takes over the service; 4. After the master loads the configuration, the new master switches to the worker working mode and restarts smoothly, and the master process number will not change.

Nginx smooth upgrade

HUP is only used for smooth restart, configuration loading, etc. If you want to upgrade nginx version smoothly 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`

Nginx process was observed, and new master and worker were created in fork. At this time, the content of nginx.pid has changed, and the file nginx.pid.oldbin was generated in the logs directory to record the old master pid.

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

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

3. Send a QUIT signal to the old master, and the old nginx process completely exits, so 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. FPM has been integrated since php5.3.3, and PHP-FPM can be opened with the–-enable-fpm parameter when. /configure.

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

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

By continuously observing the fpm process, we can see that the FPM restarts smoothly, and it needs to wait until the subprocess exits completely before starting the new master and subprocess, and then the old master exits. Further analysis using strace

The discovery master notifies all subprocesses to quit, including the subprocesses that are processing the request.

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