Re: OS Error.... again and again..

Richard Scranton (scrantr@ix.netcom.com)
Mon, 22 Sep 1997 17:04:01 -0400

Message-Id: <3426DD41.2185@ix.netcom.com>
Date: Mon, 22 Sep 1997 17:04:01 -0400
From: Richard Scranton <scrantr@ix.netcom.com>
To: Brad Templeton <brad@clari.net>
Subject: Re: OS Error.... again and again..

When you exhaust the listen queue depth, you start refusing connections.
If you have FCGI transactions that require more than 1 connection,
either
concurrently or as multiple steps in a series of chined transactions,
your [F]CGI processes will start to error out, leaving sockets in a
TIME_WAIT state.  The trouble just snowballs from there, until 5 or 10
minutes later, a bunch of TIME_WAITs expire and the sockets are free
to accept connections again.  Working as designed. :(  Busy web servers
with lots of [F]CGI happening need lots of headroom to avoid that
snowball effect.  "Right out of the gate" would worry me though.  For
the host listen queue and sockets to bee the problem, you would need
to accept a few connections to get things rolling.  Is your environment
similar to the Solaris/Apache one being discussed?  -rs

Brad Templeton wrote:
> 
> Sometimes I have seen the problem appear right out of the gate, when just
> starting the fastcgi with a kill -1 to apache.
> 
> But once it happens it never goes away until the kill -1, is that consistent
> with the running out of listen queues?  SHouldn't some of the pending
> requests eventually go away, opening up queue slots?
> 
> It does happen to *all* requests, so it's not something in one particular fork
> of the fastcgi, it's in the apache module or the OS.

-- 
===================================================================
Richard Scranton - LDA Systems - Information Management Consulting
scrantr@ix.netcom.com  Columbus Cincinnati Cleveland Toledo Atlanta