10% 500 Errors

[James Golick]

Nothing. There's nothing in the logs.

According to the mongrel mailing list, it can raise 500s when it's in err
state. But, does it respond with an incorrect error code? I dunno.

I mean, I'm not seeing anything in any error logs, and nginx is reporting a
200 for all requests. wtf?

On Mon, Mar 10, 2008 at 10:17 AM, Aníbal Rojas <anibalrojas at gmail.com>
wrote:

> But what does the production.log or mongrel logs say?
>
> I mean, can you find errors in the backend logs matching the date/time
> for the errors in the nginx log?
>
> --
> Aníbal Rojas
> http://hasmanydevelopers.com
> http://rubycorner.com
> http://anibal.rojas.com
>
> On Tue, Mar 11, 2008 at 9:17 AM, James Golick <jamesgolick at gmail.com>
> wrote:
> > Nothing... all of the mongrels respond normally when hit without nginx.
> >
> > This has got to be an nginx issue...
> >
> >
> >
> > On Mon, Mar 10, 2008 at 9:40 AM, James Golick <jamesgolick at gmail.com>
> wrote:
> >
> > > Yeah, I don't think it's mongrel, as they're all started the identical
> way
> > (thru a process monitor).
> > >
> > > 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....
> > >
> > > I will test them all and report back.
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Mar 10, 2008 at 9:29 AM, Phillip B Oldham
> > <phill at theactivitypeople.co.uk> wrote:
> > >
> > > >
> > > > 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.
> > > >
> > > > During my investigations into why this was happening in lighttpd, I
> came
> > across the following paragraph in the mod_fcgi docs:
> > > >
> > > > Adds a MaxRequestsPerProcess parameter that allows mod_fcgid to exit
> > after handling a certain number of requests, similar to the existing
> > ProcessLifeTime option.
> > > >
> > > > 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. Not too
> > sure if your rails app/mongrel is restarting processes after a set limit
> and
> > coming across the same race condition?
> > > >
> > > > 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.
> > > >
> > > > HTH.
> > > > Phill
> > > >
> > > >
> > > >
> > > >
> > > > James Golick wrote:
> > > > I have nginx running as a proxy to about twelve upstream app
> servers,
> > serving a rails app. Nothing else really in this configuration.
> > > >
> > > > I am seeing about 10% of requests throwing 500 errors, and this in
> my
> > error log:
> > > >
> > > > 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
> > > >
> > > > I'm also seeing lots of:
> > > >
> > > > client xxx closed keepalive connection
> > > >
> > > > but that strikes me as normal, and I'm seeing:
> > > >
> > > > client closed prematurely connection while reading client request
> line,
> > client: xxx, server: xxx
> > > >
> > > > I have googled far and wide, and the best answers I came up with
> were to
> > add these lines to my conf:
> > > >
> > > > proxy_ignore_client_abort  on;
> > > > proxy_next_upstream error;
> > > >
> > > > but, that doesn't seem to have solved the problem.
> > > >
> > > > Any ideas?
> > > >
> > > > Thanks in advance.
> > > >
> > > >
> > > > --
> > > >
> > > >
> > > >
> > > > Phillip B Oldham
> > > > The Activity People
> > > > phill at theactivitypeople.co.uk ________________________________
> >
> > > >
> > > > Policies
> > > >
> > > > 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.
> > > >
> > > > 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. ________________________________
> >
> > >
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20080310/5a257cc3/attachment.html>