Detailed explanation of Nginx process scheduling problem

Nginx uses a fixed number of multi-process models, in which a master process (MasterProcess) and worker processes with the same number of host CPU cores work together to handle various events.

Nginx uses a fixed number of multi-process models, in which a master process (MasterProcess) and worker processes with the same number of host CPU cores work together to handle various events.

The main management process is responsible for configuration loading, starting and stopping of the working process, and the working process is responsible for processing specific requests. The resources between processes are independent. Each worker process handles multiple connections. Each connection is fully handled by a worker process. There is no need to switch processes, and there will be no resource consumption problems caused by process switching. In the default configuration, the number of worker processes is the same as the number of CPU cores on the host. The affinity between the CPU and the process is fully utilized to bind the worker process to the CPU, thereby maximizing the processing power of the multi-core CPU.

The Nginx main process is responsible for monitoring external control signals and passing related signal operations to the worker process through the channel mechanism. Multiple worker processes share data and information through shared memory.

Tips: Process affinity enables a process or thread to run on a specified CPU (core).

Nginx's working process has the following scheduling methods:

• No scheduling mode: All worker processes will compete to establish a connection with the client when a connection event is triggered, and start processing client requests when the connection is successfully established. In the unscheduled mode, all processes will compete for resources , but ultimately only one process can establish a connection with the client. This will instantly consume a large amount of resources for the system, which is the so-called herd phenomenon.
• Mutex lock mode: Each worker process will periodically compete for the mutex lock. Once a worker process grabs the mutex lock, it means that it has the right to receive HTTP connection establishment events, and injects the socket monitoring of the current process into the event engine (such as epoll) to receive external connection events. Other worker processes can only continue to process the read and write events of the established connection and periodically poll to check the status of the mutex. Only after the mutex is released can the worker process seize the mutex and obtain the right to process the HTTP connection establishment event . When the difference between 1/8 of the maximum number of connections of the working process and the available connection (free_connection) of the process is greater than or equal to 1, the opportunity to compete for the mutex lock in this round is abandoned, and no new connection requests are accepted. Only the read and write events of the established connection are processed. The mutual exclusion lock mode effectively avoids the herd-thrashing phenomenon. For a large number of short HTTP connections, this mechanism effectively avoids resource consumption caused by worker processes competing for event processing rights. However, for a large number of HTTP connections with long connections enabled, the mutex mode will concentrate the pressure on a few worker processes, which will lead to a decrease in QPS due to uneven load on the worker processes.
• Socket sharding: Socket sharding is an allocation mechanism provided by the kernel that allows each worker process to have an identical set of listening sockets. When there is an external connection request, the kernel decides which worker process's socket listener can receive the connection. This effectively avoids the herd-thundering phenomenon and improves the performance of multi-core systems compared to the mutex lock mechanism. This feature requires enabling the reuseport parameter when configuring the listen directive.

Tips: In Nginx versions later than 1.11.3, the mutex mode is disabled by default. The socket sharding mode has the best performance because the Linux kernel provides the process scheduling mechanism.

This is the end of this article about Nginx process scheduling. For more information about Nginx process scheduling, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!