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

Richard Scranton (scrantr@ix.netcom.com)
Mon, 22 Sep 1997 14:45:26 -0400

Message-Id: <3426BCC6.59EE@ix.netcom.com>
Date: Mon, 22 Sep 1997 14:45:26 -0400
From: Richard Scranton <scrantr@ix.netcom.com>
To: Stanley Gambarin <stanleyg@cs.bu.edu>
Subject: Re: OS Error.... again and again..

We've been discussing this off-line for several days now.  My opinion
is still that the problem is the listen queue depth of the host
operating system.  The default can be determined usually by looking
at the /usr/include/sys/socket.h header for the #define SOMAXCONN
macro definition.  As an example, the HP-UX system in front of me
has a listen queue depth of "20" - much too low if were being used
as a web server.  A value of 128 or 256 would be more appropriate,
with commensurate increases in "open files/sockets per process", "max
child processes per user", "max system processes", ad inifinitum, but
you get the drift here.  I *still* think that the halts and
interruptions
being discussed are because:
	1) The listen queue depth is exhausted
	2) The majority of the available sockets are in TIME_WAIT

The following URL gives some pointers for tuning web server hosts.
Nearly all entries mention increasing the depth of the listen queue.

	http://www.apache.org/docs/misc/perf.html

-rs


Stanley Gambarin wrote:
> 
>         The only thing I can suggest at this point is the following:
> - increase your listen queue depth (contact Sun folks or check out
> newsgroups for proper command to adjust this parameter in kernel -
> no, you do not need to recompile the kernel)
> - try another OS (if possible)
> - put some debugging code in and see if you can get more information
> as to why and when this is happening, (otherwise, we are just shooting
> in the dark).
> 
>                                         Stanley.
> 
> On Mon, 22 Sep 1997 thylmann@m1.sprynet.com wrote:
> 
> > Hello,
> >
> > just wanted to tell everyone, it is still happening... Downtimes of
> > about 5 seconds to 10 minutes randomly. And suddenly it works again,
> > what exactly could cause something like that? Could it be the max
> > listen queue of the kernel? Or is it very probably a FastCGI bug?
> >
> > Thank,
> >
> > - Fabian Thylmann <aka NaTHaN>
> > STATSnet - free statistics for your WebPage!
> > http://www.stats.net
> >

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