Nginx configuration process, you understand?

Nginx process structure

In this article we look at the structure of the process of Nginx, Nginx structure in fact there are two processes:

• Single Process Structure
• Multi-process architecture

Single process structure is actually not suitable for a production environment, we do only suitable for development and debugging use. In a production environment because we must maintain robust enough and Nginx Nginx can take advantage of a characteristic of multi-core, single-process and Nginx can not do this, so the default configuration Nginx are open to multiple processes.

We look, Nginx multi-process architecture in its process model is like.

The multi-process architecture Nginx process as shown below, there will be a parent process (Master Process), it will have a lot of child processes (Child Processes), the child process will be divided into two categories:

• worker process
• cache-related processes

Why Nginx multi-process architecture rather than a multi-thread structure?

Because the core of Nginx is a purpose to maintain high availability, high reliability, and when Nginx If you are using multi-threaded architecture, because between the threads are sharing the same address space, so when a third-party modules lead to a when an address space segment error caused when address cross-border appears, will cause the entire process Nginx all hang. When multi-process model, often not such a problem. Nginx can be seen from the chart in the process of doing the design, follow the same high availability, high reliability such a purpose.

For example, in the master process, usually third-party modules will not add their own function codes in the master section. Although Nginx designed to allow third-party modules to add their own unique master in the process, since some of the methods defined, but generally do not have third-party modules.

master process is designed to make the purpose of managing worker process, that is, all the worker processes is the real deal with the request, and the master process is responsible for monitoring each worker process is not a normal job, or need to re-do load the configuration file, or need to do hot deployment.

The cache (cache) are shared between multiple worker processes, and the cache is used only to worker process, but also the cache manager and cache loader used by the process. When the cache manager and the cache loader is a reverse proxy, the rear end of the request sent to do dynamic, cache loader used by the cache is only used for loading the cache, cache manager used for cache management. In fact each request processing, use the cache or by the worker to carry out the process.

Communication between these processes, are using shared memory to solve. We can see the cache manager and cache loader have a process, master process because it is the parent process, so it must have only one. Why then the worker process will be a lot of it? This is because the use of event-driven engine Nginx later, he hoped that every worker process from start to finish possession of a CPU, it is often more than the number of worker processes should be consistent with the configuration other than the number of CPU cores on our server, also need to each worker process with a certain CPU core bound together, so you can make better use of each CPU core above CPU cache to reduce cache miss hit rate.

These are the introduction of process structure Nginx, the understanding of these will help us to better configure Nginx.

We have just introduced the Nginx uses a multi-process model, many started as a child process the parent process by the master, Nginx also know that between parent and child is a signal to management, followed by a visual example for everyone to look at the process as well as father and son how between the signal works.

Nginx examples of process structure

First start Nginx, and started two Nginx worker processes, you can see the current process PID and the parent PID with the ps command, there is a nginx master process is played by the root user, the process PID is 2368. There are two worker processes and cache process, they are made up of the 2368 process. They were 8652,8653,8655 process PID.

Now we use ./sbin/nginx -s reloadthe command, before the worker process and cache process will exit gracefully, then the new configuration items and then used to start a new worker process, where we have not changed the configuration, but we can see three old child process quit, and generate a new child process.

It can be seen before the three sub-processes, it is now not in, but by the 2368 New 8657,8658,8660 played three sub-processes.

[root@wupx nginx]# ps -ef|grep nginx
root      2368     1  0 Sep21 ?        00:00:00 nginx: master process /usr/sbin/nginx
root      4751  4688  0 11:41 pts/0    00:00:00 grep --color=auto nginx
nginx     8652  2368  0 Nov12 ?        00:00:00 nginx: worker process
nginx     8653  2368  0 Nov12 ?        00:00:00 nginx: worker process
nginx     8655  2368  0 Nov12 ?        00:00:00 nginx: cache manager process
[root@wupx nginx]# ./sbin/nginx -s reload
[root@wupx nginx]# ps -ef|grep nginx
root      2368     1  0 Sep21 ?        00:00:00 nginx: master process /usr/sbin/nginx
root      4753  4688  0 11:43 pts/0    00:00:00 grep --color=auto nginx
nginx     8657  2368  0 Nov12 ?        00:00:00 nginx: worker process
nginx     8658  2368  0 Nov12 ?        00:00:00 nginx: worker process
nginx     8660  2368  0 Nov12 ?        00:00:00 nginx: cache manager process

After executing the command worker can see the PID has changed (before talked ./sbin/nginx -s reloadwith the kill -SIGHUPeffect is the same.).

kill -SIGTERM Is sent to an existing worker processes exit signal, corresponding worker will quit the process; a process when you exit, it will automatically send a signal to the parent process to exit the master, master knew his child process exits, and then a new worker process.

[root@wupx nginx]# ps -ef|grep nginx
root      2368     1  0 Sep21 ?        00:00:00 nginx: master process /usr/sbin/nginx
root      4753  4688  0 11:43 pts/0    00:00:00 grep --color=auto nginx
nginx     8657  2368  0 Nov12 ?        00:00:00 nginx: worker process
nginx     8658  2368  0 Nov12 ?        00:00:00 nginx: worker process
nginx     8660  2368  0 Nov12 ?        00:00:00 nginx: cache manager process
[root@wupx nginx]# kill -SIGTERM 8658
[root@wupx nginx]# ps -ef|grep nginx
root      2368     1  0 Sep21 ?        00:00:00 nginx: master process /usr/sbin/nginx
root      4753  4688  0 11:44 pts/0    00:00:00 grep --color=auto nginx
nginx     8657  2368  0 Nov12 ?        00:00:00 nginx: worker process
nginx     8660  2368  0 Nov12 ?        00:00:00 nginx: cache manager process
nginx     8663  2368  0 Nov12 ?        00:00:00 nginx: worker process

By example demonstrates, we can see the structure of the process and the way Nginx Nginx use of signals, in fact, many of the command line is again sub-command signal sent master process only.