On Tue 17. 8. 2021 at 15:49, Maxim Konovalov <maxim@nginx.com> wrote:

> Hi Rob,
>
> On 17.08.2021 06:35, Robert Mueller wrote:
> > # HG changeset patch
> > # User Rob Mueller <robm@fastmail.fm>
> > # Date 1629171218 14400
> > # Mon Aug 16 23:33:38 2021 -0400
> > # Node ID 89ff95b268e9817b344447b7e6785354229a4bab
> > # Parent dda421871bc213dd2eb3da0015d6228839323583
> > Mail: add the "reuseport" option of the "listen" directive
> >
> > The "reuseport" option was added to the "listen" directive of the http
> > and stream modules in 1.9.1, but it wasn't added to the mail module. This
> > adds the option to the mail module to make it consistent with the http
> > and stream modules.
> >
> > In newer linux kernel versions (somewhere between 4.9 and 5.10) this
> > option seems much more important. On production debian servers, not
> having
> > or using this option caused processes to become very unbalanced. With 8
> > worker processes, we would see one worker process accepting 70%+ of all
> > connections, a second process with about 10% or so, and the remaining
> > 20% of connections spread over the other 6 processes. This obviously
> > started causing problems as the worker process accepting the majority
> > of connections would end up being 100% CPU bound well before the servers
> > overall capacity.
> >
> > Adding and enabling this option fixed this entirely, and now all
> > worker processes seem to accept and even spread of connections.
> >
> First, thanks for the patch.
>
> While the reuseport could cure (or hide if you will) the unbalancing you
> see it makes sense to get better understanding what exactly is going on.
> So far we haven't seen such weird behaviour ourself neither received
> reports about such uneven connections distribution among nginx workers.


Hello!

It looks exactly like known linux epoll behavior, which is nicely explained
here:
https://blog.cloudflare.com/the-sad-state-of-linux-socket-balancing/

Best, Jan Prachař


>
> Any chances you have accept_mutex and/or multi_accept? Any other ideas?
>
> --
> Maxim Konovalov
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel