The eight-startled group problem of Nginx Learning

the generation of the herd problem (thundering)
When the connection is established, Nginx is in full play multi-core CPU architecture performance considerations, using a number of worker subprocess to monitor the design of the same port, so many child processes in the accept to establish a new connection will be scrambling, this will bring the famous "surprise group" problem, the number of child processes more obvious, This can result in decreased system performance.
In general, how many CPU cores have the number of worker child processes configured. Assuming that no user is currently connected to the server, a moment when all the child processes are dormant and waiting for a new connected system call (such as epoll_wait), a user initiates a connection to the server, and the kernel activates all the hibernation worker subprocess when it receives the TCP SYN packet. Ultimately, only the child processes that first start executing the accept can successfully establish a new connection, while other worker subprocess will accept fail. The failure of these accept to wake the kernel is unnecessary, and their wake up execution is likely to be superfluous, and at this moment they are consuming resources that are not needed, causing unnecessary process switching and increasing overhead.
How to solve the-post event processing mechanism of the surprise group problem
Many of the most recent versions of the OS have solved the panic swarm problem in the event-driven mechanism, but the nginx as a very portable Web server, or at its own application level to better solve the problem. Nginx stipulates that at the same time only one worker child process listens on the Web port, and this does not surprise the cluster, at which point the new connection event wakes only the worker child process that is listening on the port.
How to limit the time when there is a child process listening to the Web port. In the case of opening the Accept_mutex lock, the current worker process will not try to listen on the web port until the Ngx_trylock_accept_mutex method is invoked.
So, when do you release the Ngx_accept_mutex lock? Obviously, we can't wait until the whole thing is done. Because there may be many active connections on this worker process, it can take a long time to handle events on these connections, and other worker processes have difficulty getting the chance to handle new connections.
How to solve the problem of long time occupy Ngx_accept_mutex. This relies on the post event handling mechanism, which nginx designed two queues: ngx_posted_accept_events queues (queues for new connection events) and ngx_posted_events queues (queues that hold normal events). Both queues are ngx_event_t types of double linked lists. The definition is as follows: [CPP]View Plain copy print?   Ngx_thread_volatile ngx_event_t *ngx_posted_accept_events; Ngx_thread_volatile ngx_event_t *ngx_posted_events;
The following combination of specific code to analyze the problem of surprise group solution.
First look at the Ngx_process_events_and_timers event handler function (SRC/EVENT/NGX.EVENT.C) in the worker process, which is in the Ngx_worker_process_cycle method of the worker process , the cyclic processing time is the core of the event-driven mechanism, dealing with both ordinary network events and timer events. Ngx_process_events_and_timers is the way Nginx actually handles the web business, and all the execution of the business starts with it, involving Nginx complete event-driven mechanisms. Especially important ~ [CPP]  View plain copy print? void   ngx_process_events_and_timers (ngx_cycle_t *cycle)    {        ngx_uint_t  flags;       ngx_msec_t  timer,  delta;          if  (ngx_timer_resolution)  {            timer = NGX_TIMER_INFINITE;            flags = 0;          } else  {           timer = ngx_event_find_timer ();            flags = NGX_UPDATE_TIME;      #if   (ngx_threads)               if   (timer == ngx_timer_infinite | |  timer > 500) &nbsP {               timer = 500;            }      #endif         }          /*ngx_use_accept_ The mutex indicates whether it is necessary to lock the accept to solve the surprise swarm problem. When Master mode is used, when the Nginx worker process number is >1 and the Accept_mutex is opened in the configuration file, this flag is placed 1        It is set in the function Ngx_event_process_int, the source code is:      if  (ccf->master &&  Ccf->worker_processes > 1 && ecf->accept_mutex)  {           ngx_use_accept_mutex = 1;           ngx_accept_mutex_held = 0;           ngx_accept_mutex_delay = ecf->accept_mutex_delay;        } else  {          ngx_use_accept_mutex = 0;       }*/       if  (Ngx_use_accept_mutex)  {            //load Balancing Process             if  (ngx_accept_disabled > 0)  {                ngx_accept_disabled--;               } else {                //call Ngx_trylock_accept_mutex method, try to get accept lock                 if  (Ngx_trylock_accept_mutex (cycle)  == ngx_error)  {                    return;     &Nbsp;          }                   //get the lock                 if  (Ngx_accept_mutex_held)  {                    /* adds flags to the flag ngx_post_events, This tag is used as a parameter of the processing time core function ngx_process_events, and all events in this function are deferred processing. Will put the accept incident to Ngx_posted_.