[Mongrel] random cpu spikes, EBADF errors

Zed A. Shaw zedshaw at zedshaw.com
Tue Oct 30 21:06:53 EDT 2007

On Tue, 30 Oct 2007 09:19:24 -0400
"Zachary Powell" <zach at plugthegap.co.uk> wrote:

> Wow, triggered a whole discussion there (most of which was over my head, at
> least at this hour). I've bumped it up to four mongrels to see if that
> solves the problem (temporarily) and I'll turn the mongrel.log debug on and
> see what I can find.

It is a common issue though with the HTTP RFC and what load balancers should be doing.  Effectively, the RFC describes a web server, proxy, and client, but not really an LB of any kind.  When people follow the RFC they get some dumb behaviors from their web server that shouldn't apply to an LB.  For example, many web servers will take the 503 responses from the backends and then show them to the end user, which if you read the RFC is kind of right but really wrong (it should try again).  Others will take the RFC literally and make a connection to a backend then hang out, which is wrong in a practical sense since that means a mis-configured backend can cripple the LB.

Imagine if the LB had to wait for the "official" TCP timeout of anywhere from 60 seconds to 200,000 days depending on the operating system.  (Yes pedants, that's exagerated.)

There's also practical considerations when dealing with heavy loaded network servers in general.  I believe that the HTTP people got this one all wrong in that they require a response, but logically if your server is overloaded, you can't give a response.

So yes, you started a useful conversation since people are going to keep hitting this over and over.  The solution of course is the following:

	** The HTTP RFC doesn't cover load balancers (or even proxy servers) in any sufficient detail to be useful. **

That's the gist of it really.

Let us know what comes of your changes.

Zed A. Shaw
- Hate: http://savingtheinternetwithhate.com/
- Good: http://www.zedshaw.com/
- Evil: http://yearofevil.com/

More information about the Mongrel-users mailing list