RE: 502 errors continue
This is what is captured in the log with "option httplog" set:
Oct 6 12:34:13 localhost haproxy: 127.0.0.1:44287
[06/Oct/2009:12:33:55.487] ourapp_staging ourapp_staging/ourapp_5002
0/0/0/-1/17769 502 204 - - SH-- 5/5/5/1/0 0/0 "GET /clients/38275/edit
I've pasted the relevant info from our log here as well:
Some more details about our environment:
We have two apps on the same server both apps use 3 mongrels.
One app uses mongrels on ports 5000 - 5002
The other app uses mongrels on ports 5100 - 5102
Both apps are configured to use haproxy.
Our haproxy.cfg can be found here:
We have monit monitor the size of our mongrels and restart them when their
memory footprint becomes too large, we believe the 502 errors are thrown on
the last request handled by the mongrel prior to the restart, but that is
just based on observations and we can not be sure how accurate that is.
From: Willy Tarreau [mailto:w <at> 1wt.eu]
Sent: Tuesday, October 06, 2009 1:37 PM
To: Ben Fyvie
Subject: Re: 502 errors continue
On Mon, Oct 05, 2009 at 04:37:16PM -0500, Ben Fyvie wrote:
> We have implemented haproxy between an nginx web server and 3 mongrel
> instances. With this configuration we receive intermittent 502 errors,
> errors seem to only occur when a single mongrel instance is restarting (at
> least that is how it seems). We were running haproxy version 188.8.131.52
> I came across the following:
> http://www.mail-archive.com/haproxy-JklxK3liFipg9hUCZPvPmw <at> public.gmane.org/msg00864.html
> So today we upgraded to 1.3.20 in hopes that our 502 problems would be
> resolved, however they continue.
> Some interesting tidbits:
> 1. without haproxy we don't receive any 502 errors
> 2. prior to the upgrade to 1.3.20 we had one request to create a new
> record. That request returned a 502 to the end-user, but the record was
> actually created (this means the mongrels are processing the requests)
> Are there steps we can take (such as specific logging options) to pinpoint
> what is causing haproxy to throw the 502 errors?
Yes, first, you should absolutely check the logs. The response is there.
Just grep for ' 502 ' in your logs and see the flags, they will indicate
what has caused that error.