upgrading binary failed - execve - too long argument list
krikkiteer at gmail.com
Mon May 10 10:02:45 UTC 2021
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 at mdounin.ru> wrote:
> 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
> > 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
> nginx mailing list
> nginx at nginx.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx