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