You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apache-bugdb@apache.org by "T. V. Raman" <ra...@Adobe.COM> on 1999/02/06 00:40:01 UTC
Re: os-solaris/3749: Apparent memory leak +httpd processes that
refuse to die
The following reply was made to PR os-solaris/3749; it has been noted by GNATS.
From: "T. V. Raman" <ra...@Adobe.COM>
To: Marc Slemko <ma...@znep.com>
Cc: "T. V. Raman" <ra...@Adobe.COM>, Apache bugs database <ap...@apache.org>
Subject: Re: os-solaris/3749: Apparent memory leak +httpd processes that
refuse to die
Date: Fri, 5 Feb 1999 15:35:09 -0800 (PST)
Hi Mark--
This is a final follow-up to the case you helped me with a
couple of weeks ago.
I reconfigured automounter on my solaris box to mount the
offending Novell servers soft,intr,
and though this diminished the problem, it did not eliminate
it. Following that reconfiguration, my server went through a
week where it got heavy use, and solaris 2.6 kept crashing
--apparently due to too many fin_wait_2 sockets. (I've read
the fin_wait_2.html document in the documentation and
understand the problem).
I finally gave up and went back to apache 1.2.6 which kept
my server up without trouble during the heavy load period.
Apache 1.3.4 is a great release, but solaris 2.6 and apache
1.3.4 are definitely not a good marriage.
I'm continuing to run 1.3.4 on my solaris box on a
non-standard port so I can play with it, but for the time
being I've gone back to 1.2.6 (sigh) for my production
server.
If there is some development in this area, I'd be happy to
test things out--
>>>>> "Marc" == Marc Slemko <ma...@znep.com> writes:
Marc> On Fri, 22 Jan 1999, T. V. Raman wrote:
>> >>>>> "marc" == marc <ma...@apache.org> writes:
>>
>>
>>
marc> Synopsis: Apparent memory leak +httpd processes
marc> that refuse to die
>> Wow-- first off, thanks for the instantaneous
>> response. (wish I get a similar response from the
>> folks responsible for solaris:-) The reason I
>> reported this as an Apache bug:
>>
>> 1) When the novell servers dont respond via NFS --and
>> the connecting WWW client goes away, Solaris/Apache
>> continues to wait for the NFS system to respond
>> --this is possibly buggy behavior on Solaris' part
>>
>> On the apache side, the problem is that the httpd
>> processes that get stuck in this way dont die and
>> continue to consume resources.
Marc> The Apache process can't do anything until the
Marc> blocking IO function that it is calling completes.
Marc> When that happens, depends on the OS. By default,
Marc> NFS is (properly) quite "good" about never giving
Marc> an error but just keeping retrying until it works
Marc> properly. This is necessary in the general case
Marc> to avoid unnecessary data loss due to temporary
Marc> disconnections.
Marc> If the mounts are primarily being used to serve
Marc> files to the web, then this may not be necessary.
Marc> You may want to configure your mounts to give an
Marc> error more quickly. See the mount_nfs man page
Marc> for options like soft, intr, timeo, and retrans.
Marc> What resources do the Apache processes continue to
Marc> consume? What does a truss on one of the hung
Marc> processes show?
--
Best Regards,
--raman
Adobe Systems Tel: 1 408 536 3945 (W14-128)
Advanced Technology Group Fax: 1 408 537 4042
W14-128 345 Park Avenue Email: raman@adobe.com
San Jose , CA 95110 -2704 Email: raman@cs.cornell.edu
http://labrador.corp.adobe.com/~raman/ (Adobe Intranet)
http://cs.cornell.edu/home/raman/raman.html (Cornell)
----------------------------------------------------------------------
Disclaimer: The opinions expressed are my own and in no way should be taken
as representative of my employer, Adobe Systems Inc.
____________________________________________________________