Mathew Heard
May 04, 2021 08:44PM
Maxim,

Out of curiosity I checked some of my servers with "ss -l -t -p | grep
nginx | wc -l"

I'm at 15k at most. Large numbers of worker processes make it relatively
easy to hit the ~20k limit it seems.

With Regards,
Mathew

On Wed, 5 May 2021 at 01:53, Maxim Dounin <mdounin@mdounin.ru> wrote:

> Hello!
>
> On Fri, Apr 30, 2021 at 11:14:48AM +0200, Charlie Kilo wrote:
>
> > correction.. if i count with
> > ss -l -t |grep http | wc -l
> > we have around 58340 listening sockets.. at least on that machine..
>
> Since "listen ... reuseport;" implies a separate listening socket
> for each worker process, that's expected with 50 worker processes
> and 1200 "listen ... reuseport" in the configuration.
>
> > On Fri, Apr 30, 2021 at 8:27 AM Charlie Kilo <krikkiteer@gmail.com>
> wrote:
> >
> > > Thanks a lot for the hints so far.. to provide the further info and
> answer
> > > the questions..
> > >
> > > getconf ARG_MAX shows 2097152
> > > ulimit -s shows 8192
> > > setting it to unlimited, doesn't change anything (also not with
> prlimit)
> > > wc -c /proc/<pid>/environ shows 1949
> > >
> > > it seems on a regular machine we have around 1200 listening sockets
> and do indeed use "reuseport"
>
> Thanks, so all seem to be using the defaults.
>
> Looking more closely at Linux limits, it seems that you are
> hitting the MAX_ARG_STRLEN limit. It limits single argument
> length (and a single environment variable length), and hardcoded
> to be 32 pages, that is, almost always 128k.
>
> With 128k limit nginx should be able to pass about 20k listening
> sockets, so with 58340 sockets you are well above the limit.
>
> An obvious workaround would be to reduce the amount of listening
> sockets - either by dropping the "reuseport", or by reducing the
> the number of listening sockets (normally just one on the wildcard
> address is enough), or by reducing the number of worker processes.
>
> It would be interesting to know why you are using such a large
> number of listening sockets with reuseport enabled. If the use
> case is reasonable, we probably should consider implementing some
> workaround for the 128k limit.
>
> --
> 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: 261
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 500 on July 15, 2024
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready