Nginx multi-process mode

Nginx's multi-process mode

After nginx is started. There will be one master process and multiple worker processes. The master process is mainly used to manage the worker process, including: receiving signals from the outside world. Send a signal to each worker process to monitor the execution status of the worker process. When the worker process exits (under abnormal conditions), it will automatically start a new worker process again. The main network events are handled in the worker process. Multiple worker processes are peer-to-peer. They compete equally for requests from clients, and the processes are independent of each other. a request. It is only possible to process in a worker process, and a worker process cannot process requests from other processes. The number of worker processes can be set. Generally, we will set it to be consistent with the number of machine cpu cores. The reason for this is inseparable from the nginx process model and event processing model.

 

Multi-process single thread

Nginx implements the encapsulation of epoll itself, which is a typical representative of multi-process single-threaded. Using multi-process mode can not only increase the concurrency rate, but also the processes are independent of each other, and the hang of a worker process will not affect other worker processes.

The master process manages the worker process:

  1. Receive signals from the outside world.
  2. Send a signal to each worker process.
  3. Monitor the running status of the worker process.
  4. When the worker process exits (under abnormal conditions), the new worker process will be restarted automatically.

Pay attention to the number of worker processes, generally set to the number of machine cpu cores. Because more workers will only cause the processes to compete with each other for cpu, which will bring unnecessary context switching.

Multi-process single thread

Nginx implements the encapsulation of epoll itself, which is a typical representative of multi-process single-threaded. Using multi-process mode can not only increase the concurrency rate, but also the processes are independent of each other, and the hang of a worker process will not affect other worker processes.

The master process manages the worker process:

  1. Receive signals from the outside world.
  2. Send a signal to each worker process.
  3. Monitor the running status of the worker process.
  4. When the worker process exits (under abnormal conditions), the new worker process will be restarted automatically.

Pay attention to the number of worker processes, generally set to the number of machine cpu cores. Because more workers will only cause the processes to compete with each other for cpu, which will bring unnecessary context switching.

IO multiplexing model epoll

Multiplexing allows us to return control to the program only when an event occurs, and at other times the kernel suspends the process and stands by at any time.

Epoll applies for a simple file system in the Linux kernel (the file system is generally implemented with a B+ tree data structure), and its workflow is divided into three parts:

  1. Call int epoll_create(int size) to create an epoll object. The kernel will create an eventpoll structure to store the events added to the epoll object through epoll_ctl(). These events will be mounted in the red-black tree.
  2. Call int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event) to register events for fd in the epoll object. All events added to epoll will establish a callback relationship with the device driver, that is, when the corresponding When an event occurs, the sockfd callback method is called to add sockfd to the double-linked list in eventpoll.
  3. Call int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout) to wait for the event to occur. When the timeout is -1, the call will block until an event occurs.

After registering the event, as long as there is an event on fd, epoll_wait() can detect it and return it to the user, and the user will not block when the blocking function is executed.

epoll() maintains a linked list in the kernel, and epoll_wait directly checks whether the linked list is empty to know if there is a file descriptor ready. By the way , the biggest advantage of epoll compared with select and poll is that it will not reduce efficiency as the number of sockfd grows. When using select(), the kernel uses a round-robin method to check if fd is ready, and save sockfd. It is an array-like data structure fd_set, the key is fd, and the value is 0 or 1 (time of occurrence).

epoll() can achieve this effect because in the kernel implementation, epoll is implemented according to the callback function established with the device driver on each sockfd. Then, when an event on a sockfd occurs, the callback function corresponding to it will be called, and the sockfd will be added to the linked list, and the other “idle” state will not. At this point, epoll implements a "pseudo" AIO.

It can be seen that because there is only one thread in a process, a process can only do one thing at the same time, but it can handle multiple requests "simultaneously" by constantly switching.

Example: Nginx will register an event: "If a connection request from a new client arrives, then notify me", after that, only when the connection request comes, the server will execute accept() to receive the request. For example, when forwarding a request to an upstream server (such as PHP-FPM) and waiting for the request to return, the processing worker will not block here. After sending the request, it will register an event: "If the buffer receives data , Tell me, I will read it in again", so the process is idle and waiting for the event to occur.

In this way, based on multi-process +epoll, Nginx can achieve high concurrency.

worker process workflow

When a worker process is connected to accept(), it starts to read the request, parse the request, process the request, generate data, and then return it to the client. Finally, it disconnects and completes the request. A request is completely processed by the worker process and will only be processed in one worker process. advantage:

  1. Save the overhead caused by the lock. Each worker process works independently of each other and does not share any resources, so no locks are required. At the same time, it will be much more convenient when programming and troubleshooting.
  2. Independent process to reduce risks. The use of independent processes can prevent each other from affecting each other. After a process exits, other processes are still working, the service will not be interrupted, and the master process will quickly restart the new worker process. Of course, the worker process itself can also exit unexpectedly.

Guess you like

Origin blog.csdn.net/luzhensmart/article/details/112578446