Bug 53581

Summary:	Stronghold / Apache secure apache/stronghold servers bring network service down under load
Product:	[Retired] Red Hat Linux	Reporter:	Need Real Name <diarmuid>
Component:	apache	Assignee:	Joe Orton <jorton>
Status:	CLOSED WONTFIX	QA Contact:	David Lawrence <dkl>
Severity:	high	Docs Contact:
Priority:	medium
Version:	7.1
Target Milestone:	---
Target Release:	---
Hardware:	ia64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-09-21 10:31:33 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Need Real Name 2001-09-12 10:16:44 UTC

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)

Description of problem:
When I use a secure Strongohld web server on a 4 CPU IA64 machine under a 
peak load, eventually the machines network fxnality stops working.  i.e. 
No ping, ftp, telnet, http, .....  I generate the load on the web server 
using Radviews web load application (which does not run on the server 
itself, it simulates web traffic).  The problem can be fixed by simply 
restarting the network interface (ifdown/up), until it happens again.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Start a secure Stronghold web server.
2.Set up a load (I used webload) that drives the server at peak load. Peak 
load should be around 600 tps on a 4 CPU 800Mhz IA64 (Lion) system.  My 
webload setup was requesting 20 byte web pages over ssl (https).


Actual Results:  The servers' network functionality will crash, but I've 
seen it take between 2 and 10 hours.  Using the ifdown and ifup network 
scripts will restore network activity until the next time....

Expected Results:  The network services not to stop working!

Additional info:

Stronghold I used is a prerelease of the next release of SH, but I've been 
informed that it is stable.  Reference : Mark Cox of Redhat.  Email : 
mjc.  Please contact Mark in relation to this.
My email is diarmuid.

Distribution is RedHat 7.1.

Here is the output from lsmod on the server machine...
Module                  Size  Used by
autofs                 29680   1  (autoclean)
eepro100               45048   1  (autoclean)
ipchains               98496   0  (unused)
nls_iso8859-1           4672   1  (autoclean)
nls_cp437               6176   1  (autoclean)
vfat                   25944   1  (autoclean)
fat                    81880   0  (autoclean) [vfat]
usb-uhci               65184   0  (unused)
usbcore               139680   1  [usb-uhci]
qla1280               121816   3

Comment 1 Need Real Name 2001-09-12 13:07:40 UTC

I have verified that this problem also occurs when using a non secure web 
server (http requests) with the load also generated using the WebLoad 
application.  It seems to manifest itself quicker like this (about 100 minutes 
to fail when I tested it).  This is probably because there is higher network 
throughput when in non secure mode.  (The test was doing around 3000 SSL 
transactions per second).

I ran the "dmesg" command for the first time (after we lost network fxnality) 
and there was the following interesting messages there...

eth0 card reports no resources
eth0 : 0 multicast blocks dropped

Again bringing down and up eth0 fixes the problem.

Comment 2 Arjan van de Ven 2001-11-05 10:26:57 UTC

Which kernel is this, and which network card ?

Comment 3 Need Real Name 2001-11-09 15:59:12 UTC

The kernel is the 2.4.3-12 SMP kernel.  I'm not sure what the NIC card is 
because it's built into the machine we're using.  The machine is a 4cpu lion(?) 
which we received from Intel.  Should I try and find details on the nic 
interface?

Comment 4 Joe Orton 2004-09-21 10:31:33 UTC

Thanks for the report.  This is a mass bug update; since this release
of Red Hat Linux is no longer supported, please either:

a) try and reproduce the bug with a supported version of Red Hat
Enterprise Linux or Fedora Core, and re-open this bug as appropriate
after changing the Product field, or,

b) if relevant, try and reproduce this bug using the current version
of the upstream package, and report the bug upstream.