httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Murcko <ch...@n2k.com>
Subject Re: BSDI 2.1 Apache 1.1.1 Zombie "D" Status Processes (fwd)
Date Sun, 08 Dec 1996 20:05:19 GMT
How many connections have you got in the FIN_WAIT_2 state, or put another
way, does netstat -f inet -n show you a bunch of connects to port 80?
Each of these represent kernel mbuf space slowly being eaten up.

We currently show 2920 of 'em here. I think 120 sec. is the TCP state timeout
for other states, but perhaps not FIN_WAIT_2. They're caused by browsers
breaking a connection in progress, and never sending a last ACK. Just before
things got really bad, you'd see some type of 120 sec. behavior.

I have my own suspicions about which browsers/TCP stacks those are. 8^)

Since the FIN_WAIT_2 connects never seem to time out, they accumulate until
we get a machine panic/reboot, every few days. Bill Cheswick's answer and
ours is to allocate a pile of mbufs and mbuf clusters, and reboot the machine
periodically. C'est la vie, unless BSDI adds a timeout to FIN_WAIT_2.

> ----- Forwarded message from Brian Hess -----
> 
> 
> I am still having the zombie 'd' process using 1.2b1.  Check out
> www.usaor.net/status
> 
> --brian
> 
> 
> ----- Forwarded message from Brian Hess -----
> 
> Date: Sun, 8 Dec 1996 09:53:18 -0500 ()
> From: Brian Hess <brian@usaor.net>
> To: robh@imdb.com
> Subject: Re: BSDI 2.1 Apache 1.1.1 Zombie "D" Status Processes (fwd)
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> 
> 
> Here is another person having the problem
> 
> ----------
> Brian Hess
> Network Administrator           Phone: 412-391-4382
> USA OnRamp                      Email: brian@usaor.net
> 
> 
> ---------- Forwarded message ----------
> Date: Sat, 7 Dec 1996 15:46:40 -0500 (EST)
> From: Craig Nordin <cnordin@vni.net>
> To: Brian Hess <brian@usaor.net>
> Subject: Re: BSDI 2.1 Apache 1.1.1 Zombie "D" Status Processes
> 
> 
> Yes, the hack is in, embellished with a signal(SIGALRM,_exit());
> call just before the alarm call.
> 
> It is still nerve-racking, but I'm not getting any complaints about
> anything and we do 300,000 hits on a busy day.
> 
> 
> 
> > 
> > 
> > Craig,
> > 
> > Through the beauty of DejaNews I stumbled across this article.  I am
> > having this exact same problem.  What did you ultimately find out?  Did
> > you just leave the hack in or have someone addressed this problem since
> > this post?
> > 
> > --brian
> > 
> > ---- your message ------
> > We are running BSDI 2.1 with all of the patches and running
> > Apache 1.1.1.
> > 
> > It appears that, after going to BSDI 2.1, Apache (even the 1.00
> > that I was using previously) would slowly build up some kind
> > of baggage that would eventually cause web connections to hang.
> > 
> > We are running 500,000 hits on some days and this "hang" might
> > take 1/2 to 2 days to come to.
> > 
> > When I got to Apache 1.1.1 I ran up the scoreboard and found
> > processes that would go into "D" status and then stay there
> > until they were killed.
> > 
> > Well, yes, I'm a slimy blind-curve-passing hack and I put in
> > an alarm(120) just as apache began to lookup the DNS, and put
> > another alarm(0) just as it finished.  Hehehehehe... I'm still\
> > a little nervous, but the dagone httpd "D" zombies seem to 
> > kill themselves off at just exactly 120 seconds as the scoreboard
> > says. 
> > 
> > I may have my problem licked but I'm not sure and I'm nervouse
> > about my "whacko" solution.  Has anyone else seen this problem and
> > does anyone have any suggestions or comments?
> > 
> > Cheers!
> > 
> > 
> > 
> > ----------
> > Brian Hess
> > Network Administrator           Phone: 412-391-4382
> > USA OnRamp                      Email: brian@usaor.net
> > 
> > 
> 
> 
> ----- End of forwarded message from Brian Hess -----

chuck
Chuck Murcko	N2K Inc.	Wayne PA	chuck@telebase.com
And now, on a lighter note:
"The subspace _W inherits the other 8 properties of _V. And there aren't
even any property taxes."
		-- J. MacKay, Mathematics 134b

Mime
View raw message