Identifying "Writing" connections in status stub
Maxim Dounin
mdounin at mdounin.ru
Sat Jul 29 23:47:58 UTC 2017
Hello!
On Wed, Jul 26, 2017 at 06:05:28PM +0200, Vlad K. wrote:
> On 2017-07-26 13:36, Peter Booth wrote:
> > Vlad,
> >
> > I'd suggest beginning by seeing whether or not this is real. If you
> > create a cron job that invokes netstat -ant every hour, then summarize
> > the connections and either view them manually or write them into an
> > influxdb and graph with grafana you will see whether or not the #tcp
> > connections really is growing and, if so, which connections are
> > growing.
>
> Thanks for the suggestion, but with it slow progression and low
> signal-to-noise ration in comparison with the daily and weekly
> connection cycle, I'm not sure it would be practically possible to
> measure it like that. But your suggestion gave me another idea, to
> record IPs of established tcp conns every 5 minutes and then see which
> ones remain constant.
>
> But are you suggesting that nginx status is reporting wrong/fake
> numbers? What do you mean by "real"?
>
> And what about connections that are staying in "CLOSED" state until I
> restart or reload nginx?
Connections in "CLOSED" state are likely leaked sockets. On a
reload nginx should write appropriate alerts to error log, saying
something like "open socket #<fd> left in connection <n>". These
alerts are logged in appropriate connection numbers, and details
of a particular connection can be traced through debug log.
It might not be trivial to debug such socket leaks though, and
before doing anything else it is in general a good idea to:
- make sure you are using latest nginx version, and
- the problem is not in a 3rd party module (that is, you can
reproduce it without 3rd party modules).
--
Maxim Dounin
http://nginx.org/
More information about the nginx
mailing list