upgrading binary failed - execve - too long argument list

[Maxim Dounin]

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/