[955] in linux-net channel archive
heavily-accessed site w/ random hangs on specific port... suggestions? (fwd)
daemon@ATHENA.MIT.EDU (Michael Brennen)
Tue Aug 22 03:04:29 1995
Date: Mon, 21 Aug 1995 10:02:00 -0500 (CDT)
From: Michael Brennen <mbrennen@puddytat.intecom.com>
To: linux-net@vger.rutgers.edu
cc: Eric Ost <emo@cica.cica.indiana.edu>
This was originally posted to the wu-ftpd list, but it can perhaps best
find an answer on linux-net. CICA is a very visible sight, and I for one
would hate to see it pulled off of Linux. Please copy Mr. Ost directly in
any responses, as he may not be subscribed to linux-net. Others on
linux-net may be interested in the response (I know I have seen something
like this very occasionally), so please consider responding to the list.
I hope he has not already posted this to linux-net and I haven't seen it
yet!!!
Michael Brennen
***************************************************************************
---------- Forwarded message ----------
Date: Sat, 19 Aug 1995 20:54:24 -0500
From: Eric Ost <emo@cica.cica.indiana.edu>
To: wu-ftpd@wugate.wustl.edu
Subject: heavily-accessed site w/ random hangs on specific port... suggestions?
Greetings All,
I've read testimonials from folks who administer active Internet
sites which are using Linux on a PC and I am hoping that a few
of you will read this note and be able to offer some suggestions.
Has anyone else experienced problems similar to the ones described
below and what corrective actions were taken to resolve them?
Our site hosts one of the world's most active ftp sites: the CICA ftp software
archive. It also runs httpd and gopher servers as well as handling
a normal load of email and system-related work, e.g. compiles, file edits,
etc.
Here is the current configuration:
Hardware
-----------------------------------------------------------------------------
Intel Neptune PCI chipset
Micronics motherboard with P5-90
128MB RAM
6 GB disk (Seagate 2GB Barracuda, Seagate 4GB Hawk)
Buslogic 946C SCSI-2, PCI controller
SMC EtherPower PCI NIC
-----------------------------------------------------------------------------
Software
-----------------------------------------------------------------------------
Slackware 2.3
Linux 1.2.10
xinetd 2.1.4-linux.3 (master server)
wu-ftpd 2.4 (ftp server)
NCSA httpd 1.4.1 (http server)
gn 2.08 (gopher server)
-----------------------------------------------------------------------------
We have been experiencing strangeness whereby the system "burps" for a,
sometimes extended, period of time, and connections to port 21 are not
possible -- they just timeout. However, we configured an ftp service
for port 1111 and have discovered that during a "burp" on port 21,
connections to wu-ftpd running on port 1111 are just fine. Telnet (login)
to the machine also works speedily. Random delays have occurred with as low
as 90 and as high as 190 simultaneous connections to port 21; the more
connections, the more likelihood of a delay...
In all of the above instances, xinetd is playing the role of mediator
between the incoming request and invoking the proper server.
We have noticed that "netstat" reveals a number of tcp connections in state
FIN_WAIT2. We reduced the default and max timeouts for wu-ftpd to 300 and 600
seconds, respectively, thinking that perhaps the delays were due to a scarcity
of sockets, with needed resources being tied up in FIN_WAIT2. Reducing
the timeout has reduced the number of processes in FIN_WAIT2, but has not
prevented the random delays.
The question arises: why do ftp connections to port 1111, telnet/login
to port 23, and smtp via port 25 all connect immediately without delay*?
Connections to these ports depend on allocation of sockets just like the ftp
connection requests to port 21. What are the causative differences here?
Log file data seems to indicate that wu-ftpd is not being forked by
xinetd on port 21 during these burps while wu-ftpd is being forked speedily
in response to port 1111 requests. Thus, the problem does not appear
to be directly caused by wu-ftpd. Nor does it appear to be caused by
xinetd. If wu-ftpd can be initiated on port 1111 by xinetd, why
can't the same executable be forked to communicate with port 21?
During these random delays existing connections on port 21 do not seem to
be adversely effected.
Thinking that lightening the load of xinetd might be in order, we are
now running one instance of xinted on ports 21 and 1111 with another
instance on all the other ports. The delays continue at random times on
port 21 while during these periods connections to port 1111 are speedily
answered.
At one point the kernel parameter NSOCKETS_LINUX in <net.h> was increased
to 2048, but that did not make any difference either.
Does anyone have suggestions for further investigation or possibly a
method for resolving this quandary? We have attempted to systematically
narrow the search to focus on the source of the problem. Now we are
wondering if there may be some kind of resource-wait deadlock happening
occasionally somewhere in the system.
We have been "hanging in there" with Linux for a variety of reasons.
However, we are reaching a point where the problem has become an acute
nuisance and so have been giving serious consideration to switching OS's,
e.g. FreeBSD.
Any assistance or suggestions folks may lend to resolution of this problem
will be greatly appreciated. The net is a great resource; especially, the
thousands of folks working on developing kernel and application level
code for Linux.
Any words of wisdom out there?
Thanks,
eric
