Shulou(Shulou.com)06/02 Report--

Today's article focuses on the reload process of Nginx. In fact, in the previous article, we all executed the nginx-s reload command when we changed the nginx configuration file. The reason we execute this command is that we hope that nginx does not stop the service and smoothly updates the old nginx.conf configuration to the new nginx.conf configuration while processing new requests.

Such a feature is necessary for nginx, but sometimes we find that the number of worker child processes increases after executing the nginx-s reload command, because the worker process running in the old configuration has not exited for a long time, and there may be more such scenarios when using stream as a four-tier reverse proxy.

So let's explore what nginx has done by analyzing the reload process of nginx. What's the difference between an elegant exit and an immediate exit?

Reload process

The first step is to send a HUP signal to the master process after modifying the nginx configuration file nginx.conf, which is actually the same as executing the nginx-s reload command on the command line.

Then after receiving the HUP signal, the master process will check whether the syntax of our configuration file is correct in the second step, that is to say, we do not have to perform nginx-t verification before nginx-s reload to check whether the syntax is correct, because the master process of nginx will certainly perform this step in the second step.

After the nginx configuration syntax is all correct, the master process will open a new listening port. Why open a new listening port in the master process? Because we may introduce new listening ports in nginx.conf, such as 443 or those that we did not open before, and all worker processes are child processes of the master process, the child processes inherit all the open ports of the parent process, which is defined by the linux operating system, so step 3, our master process opens a new listening port that may be introduced.

Then the mster process starts the new worker child process with the new nginx.conf configuration file, so what happens to the old worker child process?

In the fifth step, after starting the new worker child process, the master process sends the QUIT signal to the old worker child process. The QUIT signal is different from the TERM,INT signal. The QUIT signal is to gracefully close the child process. At this time, you need to pay attention to the order, because the nginx needs to be smooth, so start the new worker sub-process first, and then send the QUIT signal to the old worker sub-process.

So after the old master child process receives the QUIT signal, it first closes the listening handle, that is, at this time, the new connection will only go to the new worker child process, so although there is a time difference between them, but the time is very fast, then close the listening handle and finish the process after processing the current connection.

Let's take a look at the diagram of reload loading the new configuration without downtime.

Reload loads new configurations without downtime

There used to be four green worker child processes on the master process, they used the old configuration, when we changed the nginx.conf configuration file, send SIGHUP signal to master or execute the reload command, and then master will start four new yellow worker child processes with the new configuration file, at this time, four old green worker child processes and four new yellow worker child processes coexist. Then the old worker subprocess normally closes the connection after processing the request on the established connection, even if the connection is a keeplive request.

But in abnormal cases, if there is a problem with some requests that cannot be processed by the client for a long time, it will cause the request to stay in the worker subprocess for a long time, then the worker subprocess will exist for a long time, because the new connection is already running in the yellow worker subprocess, so the impact will not be great. The only thing that will affect is that the green worker subprocess will exist for a long time. However, it only affects existing connections, not new ones.

What can we do to deal with it? A new configuration worker_shutdown_timeout is provided in the new version, that is, how long to wait, so that after the master process starts the new yellow worker process, if the old worker process has not exited, the time will be forced to exit the old worker process.

Summary

This article focuses on the process of Nginx smoothly upgrading new configuration files, and after we understand the relationship between gracefully shutting down the worker child process and starting the newly configured worker child process, we can better handle rare exception scenarios.

The above is the whole content of this article, I hope it will be helpful to your study, and I also hope that you will support it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.