background of the problem:
when establishing a connection, Nginx takes the performance of multicore CPU architecture into full play, using multiple worker sub-processes to listen to the same port design, so that multiple sub-processes will compete when accept establishes a new connection, which will lead to the famous "shock group" problem. The more the number of child processes, the more obvious, which will lead to a decline in system performance.
how to solve the surprise group problem-post event handling mechanism
the latest version of the kernel of many operating systems has solved the panic problem in the event-driven mechanism, but Nginx, as a highly portable web server, has solved this problem at its own application level.
Nginx stipulates that only one worker subprocess listens to the web port at a time, so there will be no alarm, and the new connection event can only wake up the only worker subprocess that is listening to the port.
how to restrict that there is a child process listening on the web port at a certain time? With the accept_mutex lock on, the current worker process will not try to listen on the web port until the ngx_trylock_accept_mutex method is called.
my question:
assume that all current woker processes are dormant. When a connection event occurs, do all wokrer processes try to acquire a lock and handle the connection event if it is successful. In this case, won"t it also lead to awakening all wokrer processes to compete for locks when a connection event occurs?
the surprise group problem is to solve the following problems
in a solution that uses locks, how to prevent multiple worker processes from being awakened to contend for locks?