Nothing... all of the mongrels respond normally when hit without nginx.<br><br>This has got to be an nginx issue...<br><br><div class="gmail_quote">On Mon, Mar 10, 2008 at 9:40 AM, James Golick <<a href="mailto:jamesgolick@gmail.com">jamesgolick@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Yeah, I don't think it's mongrel, as they're all started the identical way (thru a process monitor).<br>
<br>Also, every time I get the error, I see one of those issues in the nginx error.log. But, I guess it still could be happening upstream....<br>
<br>I will test them all and report back.<div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">On Mon, Mar 10, 2008 at 9:29 AM, Phillip B Oldham <<a href="mailto:phill@theactivitypeople.co.uk" target="_blank">phill@theactivitypeople.co.uk</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Helvetica, Arial, sans-serif">I was seeing
something similar with PHP5 fastcgi and lighttpd, though it was a lot
more than 10% - maybe 25-50. I'm getting a little worried as I think I
may be seeing the same thing at around 5-10% with nginx.<br>
<br>
During my investigations into why this was happening in lighttpd, I
came across the following paragraph in the mod_fcgi docs:<br>
<blockquote type="cite">Adds a MaxRequestsPerProcess parameter that
allows mod_fcgid
to
exit after handling a certain number of requests, similar to the
existing ProcessLifeTime option. <br>
<br>
This solves a problem with PHP in FastCGI mode. By default,
PHP stops
accepting new FastCGI connections after handling 500 requests;
unfortunately, there is a potential race condition during the PHP
cleanup code in which
PHP can be shutting down but still have the socket open, so mod_fcgid
under heavy load can send request number 501 to PHP and have it
"accepted", but then
PHP appears to simply exit, causing errors.</blockquote>
Not too sure if your rails app/mongrel is restarting processes after a
set limit and coming across the same race condition?<br>
<br>
If this problem is could become aparent in nginx it would be great if
there was a plugin to spawn and manage fcgi threads which could limit
the number of connections to each backend.<br>
<br>
HTH.<br>
Phill<br>
</font></font><div><div></div><div><br>
James Golick wrote:
<blockquote type="cite">I have nginx running as a proxy to about twelve upstream
app servers,
serving a rails app. Nothing else really in this configuration.<br>
<br>
I am seeing about 10% of requests throwing 500 errors, and this in my
error log:<br>
<br>
2008/03/10 08:41:05 [info] 6632#0: *12005 client closed prematurely
connection while sending response to client, client: xxx, server: xxx,
request: xxx, host: xxx, referrer: xxx<br>
<br>
I'm also seeing lots of:<br>
<br>
client xxx closed keepalive connection<br>
<br>
but that strikes me as normal, and I'm seeing:<br>
<br>
client closed prematurely connection while reading client request line,
client: xxx, server: xxx<br>
<br>
I have googled far and wide, and the best answers I came up with were
to add these lines to my conf:<br>
<br>
proxy_ignore_client_abort on;<br>
proxy_next_upstream error;<br>
<br>
but, that doesn't seem to have solved the problem.<br>
<br>
Any ideas?<br>
<br>
Thanks in advance.<br>
</blockquote>
<br>
</div></div><div>-- <br><font color="#888888">
<div style="font-family: sans-serif; font-style: normal; font-variant: normal; font-weight: normal; font-size: 12px; line-height: 1.1; font-size-adjust: none; font-stretch: normal; width: 300px; color: rgb(51, 51, 51);">
<p><b>Phillip B Oldham</b><br>
The Activity People<br>
<a href="mailto:phill@theactivitypeople.co.uk" target="_blank">phill@theactivitypeople.co.uk</a></p>
<hr size="1">
<p style="font-size: 90%;"><b>Policies</b></p>
<p style="font-size: 90%;">This e-mail and its attachments are intended
for the above named recipient(s) only and may be confidential. If they
have come to you in error, please reply to this e-mail and highlight
the error. No action should be taken regarding content, nor must you
copy or show them to anyone.</p>
<p style="font-size: 90%;">This e-mail has been created in the
knowledge that Internet e-mail is not a 100% secure communications
medium, and we have taken steps to ensure that this e-mail and
attachments are free from any virus. We must advise that in keeping
with good computing practice the recipient should ensure they are
completely virus free, and that you understand and observe the lack of
security when e-mailing us.</p>
<hr size="1">
</div>
</font></div>
</div>
</blockquote></div><br>
</div></div></blockquote></div><br>