The following reply was made to PR os-solaris/3749; it has been noted by GNATS.
From: "T. V. Raman" <[EMAIL PROTECTED]> To: Marc Slemko <[EMAIL PROTECTED]> Cc: "T. V. Raman" <[EMAIL PROTECTED]>, Apache bugs database <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> writes: Marc> On Fri, 22 Jan 1999, T. V. Raman wrote: >> >>>>> "marc" == marc <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] San Jose , CA 95110 -2704 Email: [EMAIL PROTECTED] 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. ____________________________________________________________