<div dir="ltr">Hi,<div><br></div><div>Just getting back to you. Sorry about the delay.</div><div><br></div><div>This behaviour was caused by a custom patch in a module. The patch was ending the requests without finalizing them, leaking connections.</div><div><br></div><div>Eventually Nginx just exploded =) Nothing like production workload to stress things out.</div><div><br></div><div>Thanks a lot.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 20, 2015 at 11:04 AM, Valentin V. Bartenev <span dir="ltr"><<a href="mailto:vbart@nginx.com" target="_blank">vbart@nginx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Friday 18 December 2015 15:55:47 Marcelo MD wrote:<br>
> Hi,<br>
><br>
> Recently we added a 'thread_pool' directive to our main configuration. A<br>
> few hours later we saw a huge increase in the connections_writing stat as<br>
> reported by stub_status module. This number reached +- 3800 and is stuck<br>
> there since. The server in question is operating normally, but this is very<br>
> strange.<br>
><br>
> Any hints on what this could be?<br>
><br>
><br>
> Some info:<br>
><br>
> - Here is a graph of the stats reported, for a server with thread_pool and<br>
> another without: <a href="http://imgur.com/a/lF2EL" rel="noreferrer" target="_blank">http://imgur.com/a/lF2EL</a><br>
><br>
> - I don`t have older data anymore, but the jump from <100 to +- 3800<br>
> connections_writing happened in two sharp jumps. The first one following a<br>
> reload;<br>
><br>
> - The machines' hardware and software are identical except for the<br>
> thread_pool directive in their nginx.conf. They live in two different data<br>
> centers;<br>
><br>
> - Both machines are performing normally. Nothing unusual in CPU or RAM<br>
> usage. Nginx performance is about the same.<br>
><br>
> - Reloading Nginx with 'nginx -s reload' does nothing. Restarting the<br>
> process brings connections_writing down.<br>
</span>[..]<br>
<br>
As I understand from your message everything works well.  You should also<br>
check the error_log, if it doesn't have anything suspicious then there is<br>
nothing to worry about.<br>
<br>
The increased number of writing connections can be explained by increased<br>
concurrency.  Now nginx processing cycle doesn't block on disk and can<br>
accept more connections at the same time.  All the connections that were<br>
waiting in listen socket before are waiting now in thread pool.<br>
<br>
  wbr, Valentin V. Bartenev<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Marcelo Mallmann Dias<br></div>
</div>