Nginx process structure
Nginx has two types of process structure:
- Single process structure
- Multiprocess structure
The single-process structure is actually not suitable for production environment, only suitable for us to do development and debugging. Because in a production environment we have to keep Nginx robust and take advantage of one of the features of multi-core, which single-process Nginx cannot do, the default configuration is to turn on multi-process Nginx.
Let’s take a look at what the process model looks like in a multi-process Nginx structure.
Nginx Processes have a Master Process and a number of Child Processes, which can be divided into two types:
- Worker processes
- Cache-related processes
Why Nginx uses multi-process architecture instead of multi-thread architecture?
The core purpose of Nginx is to maintain high availability and reliability. When Nginx uses a multi-threaded structure, threads share the same address space, so when a third-party module causes a segment error caused by an address space, when the address is out of bounds, Will cause the entire Nginx process to hang. This problem often does not occur when using a multi-process model. As you can see from the above figure, Nginx process design also follows the purpose of achieving high availability and high reliability.
For example, in the Master process, it is not usual for third-party modules to add their own functional code to the Master section. Although Nginx is designed to allow third-party modules to add their own custom methods to the master process, no third-party modules generally do so.
The master process is designed to manage worker processes, that is, all worker processes handle real requests, while the master process is responsible for monitoring whether each worker process is working normally, whether it needs to reload configuration files, and whether it needs to do hot deployment.
The cache is shared between worker processes and is used not only by worker processes but also by cache Manager and Cache Loader processes. The cache Manager and cache Loader are also used to cache dynamic requests sent from the back end when the reverse proxy is used. The Cache Loader is used to load the cache, and the cache Manager is used to manage the cache. In fact, each request is handled by the worker process using the cache.
These processes communicate with each other using shared memory. The cache manager and cache Loader have two processes each. The master process is the parent process. So why are there many worker processes? This is because when Nginx adopts the event-driven engine, it expects each worker process to occupy one CPU from start to finish, so it is often not only necessary to configure the number of worker processes to match the number of CPU cores on our server. It is also necessary to bind each worker process to a certain CPU core, so that the CPU cache on each CPU core can be better used to reduce the hit ratio of cache failure.
The above is the introduction of Nginx process structure, understanding these will help us to configure Nginx.
Nginx uses a multi-process model, in which the master process is used as the parent process to start many child processes. The parent process is managed by signals between Nginx and its parent process.
Example of Nginx process structure
Nginx is an Nginx process that has been started by the root user, and the PID of the parent process is 2368. There are also two worker processes and cache processes, which are started by the 2368 process. Their process PID is 8652,8653,8655 respectively.
/sbin/nginx -s reload command will gracefully exit the previous worker process and cache process, and then use the new configuration to start the new worker process. Here we do not change the configuration. But we can see that the old three children exit and new children are generated.
As you can see, the previous three child processes are now gone, but instead of 2368 new three child processes 8657,8658,8660.
[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 processCopy the code/sbin/nginx -s reload is the same as kill-sighup./sbin/nginx -s reload .
Kill-sigterm is to send the exit signal to the existing worker process, and the corresponding worker process will exit. When the process exits, it will automatically send an exit signal to the parent process master, and the master will know that his child process exits, and then a new worker process will start.
[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 processCopy the codeIn this example, we can see the Nginx process structure and the way Nginx uses signals. In fact, many subcommands on the command line simply send signals to the master process.
