[PATCH] Mail: add the "reuseport" option of the "listen" directive
jan.prachar at gmail.com
Wed Aug 18 06:46:23 UTC 2021
On Tue 17. 8. 2021 at 15:49, Maxim Konovalov <maxim at nginx.com> wrote:
> Hi Rob,
> On 17.08.2021 06:35, Robert Mueller wrote:
> > # HG changeset patch
> > # User Rob Mueller <robm at 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
> > 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.
It looks exactly like known linux epoll behavior, which is nicely explained
Best, Jan Prachař
> Any chances you have accept_mutex and/or multi_accept? Any other ideas?
> Maxim Konovalov
> nginx-devel mailing list
> nginx-devel at nginx.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx-devel