>Number:         2122
>Category:       os-linux
>Synopsis:       Children do not die when heavy traffic over NFS mount
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Wed Apr 22 16:30:01 PDT 1998
>Last-Modified:
>Originator:     [EMAIL PROTECTED]
>Organization:
apache
>Release:        1.2.5
>Environment:
linux 2.1.97 (also 2.0.x, and 2.1.x)
gcc 2.7.2
Spanstor, software toaster.
>Description:
/www(this is our web server document root only) is mounted to nfs1:/1/www 
(this is the Spanstor disk array). /usr/local/web is the ServerRoot (where the
conf files, log files, and binary reside). As the number of connections rises,
(to a virtual site) the number of spawned children rise as well. Up to about 40
simultaneous children there is not really a problem, but after that, it seems 
the children do no die right away and therefore, the parent must spawn a 
seperate child to handle more incoming requests. This eventually causes the 
load average to increase, the machine to slow down, and sometimes the process
table to fill up. We've tried various nfs mounting options as well as web
server options. Nothing affects it enough to make it worthwhile. We don't have
this problem when we serve the documents off of a local disk.

We're wondering if this is a possible NFS problem with the particular NFS disk 
array system that we are trying to use, or if anyone has had other problems with
devices such as NetApps...(though i have noticed that the netapp handles this
situation a little better)
>How-To-Repeat:
put a heavy virtual site over an NFS mounted partition(using a netapp or 
spanstor)
disk array system.)
>Fix:
I'm not sure if this is an apache problem or an NFS problem honestly
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include <[EMAIL PROTECTED]> in the Cc line ]
[and leave the subject line UNCHANGED.  This is not done]
[automatically because of the potential for mail loops. ]



Reply via email to