Charlie Kilo
May 10, 2021 06:04AM
Hi!
I have to admit, my previous "details" were somewhat vague - by "tons of
traffic" i meant exactly what you described - a huge number of shortlived
connections per second (some millions in a few seconds)


On Sun, May 9, 2021 at 5:27 PM Maxim Dounin <mdounin@mdounin.ru> wrote:

> Hello!
>
> On Sat, May 08, 2021 at 10:01:19AM +0200, Charlie Kilo wrote:
>
> > Thanks Maxim for further explaining!
> >
> > We do listen to a huge number of IPs with tons of traffic and huge spikes
> > on them. We really need to avoid any type
> > of congestion, therefore the reuseport.
> >
> > While many of the ip:port combos are simply there for failover purposes
> and
> > actually aren't "in use", I see right now
> > no feasible way to reduce the number of listening sockets before the
> > upgrade and restore them afterwards. That would be hugely complex,
> > error-prone and would still leave us with a window where the instant
> > failover wouldn't work as expected.
>
> Thanks for the details.
>
> Note that "reuseport" doesn't help with "tons of traffic". It can
> help in the special case when there are a lot of new connections
> are established per second, and all these connections are
> short-lived, so a large part of CPU time is spent in establishing
> new connections.
>
> Further, "reuseport" doesn't help if there are already multiple
> listening sockets, and new connections are already distributed
> between these sockets. Its main use is when you have only one
> listening socket and want to reduce lock contention on this socket
> by providing additional listening sockets.
>
> The only case when "reuseport" is unavoidable in nginx now is when
> you want to handle UDP proxying with sessions.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Subject Author Posted

upgrading binary failed - execve - too long argument list

Charlie Kilo April 27, 2021 06:38AM

Re: upgrading binary failed - execve - too long argument list

Francis Daly April 28, 2021 08:18AM

Re: upgrading binary failed - execve - too long argument list

Maxim Dounin April 28, 2021 05:14PM

Re: upgrading binary failed - execve - too long argument list

Mathew Heard April 28, 2021 06:58PM

Re: upgrading binary failed - execve - too long argument list

Charlie Kilo April 30, 2021 02:30AM

Re: upgrading binary failed - execve - too long argument list

Charlie Kilo April 30, 2021 05:16AM

Re: upgrading binary failed - execve - too long argument list

Maxim Dounin May 04, 2021 11:54AM

Re: upgrading binary failed - execve - too long argument list

Mathew Heard May 04, 2021 08:44PM

Re: upgrading binary failed - execve - too long argument list

Charlie Kilo May 08, 2021 04:02AM

Re: upgrading binary failed - execve - too long argument list

Maxim Dounin May 09, 2021 11:28AM

Re: upgrading binary failed - execve - too long argument list

Charlie Kilo May 10, 2021 06:04AM

Re: upgrading binary failed - execve - too long argument list

itpp2012 May 10, 2021 06:53AM

Re: upgrading binary failed - execve - too long argument list

Charlie Kilo May 10, 2021 02:48PM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 229
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready