<div dir="ltr">=)<div><br></div><div>That module passed all our tests, both in dev and staging environments. We were deploying in batches and got it on the first one. We also rolled back before any incidents.</div><div><br></div><div>Not perfect but pretty safe, I think.</div><div><br></div><div>Maybe we need to be more 'creative' with our testing.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 19, 2016 at 6:47 AM, B.R. <span dir="ltr"><<a href="mailto:reallfqq-nginx@yahoo.fr" target="_blank">reallfqq-nginx@yahoo.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Testingin production?<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Well you are not the only one... far from that.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">There are other means to create 'realistic' traffic on benches, provided you are thinking those tests well, though.<br></div><div class="gmail_extra"><div><div><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font></div></div><div><div class="h5">
<br><div class="gmail_quote">On Mon, Jan 18, 2016 at 7:33 PM, Marcelo MD <span dir="ltr"><<a href="mailto:lists.md@gmail.com" target="_blank">lists.md@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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"><div><div><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>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><div><br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">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></div></div><span><font color="#888888">-- <br><div>Marcelo Mallmann Dias<br></div>
</font></span></div>
<br>_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">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></blockquote></div><br></div></div></div></div>
<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></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Marcelo Mallmann Dias<br></div>
</div>