Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 3 Aug 1998 14:40:17 +0200 (MET DST)
From:      Sascha Schumann <sas@schell.de>
To:        Brian Tiemann <btman@ugcs.caltech.edu>
Cc:        freebsd-questions@FreeBSD.ORG
Subject:   Re: More httpd process-limit problems
Message-ID:  <Pine.LNX.3.96.980803142953.11763C-100000@www.schell.de>
In-Reply-To: <Pine.BSF.4.02.9808030020451.2418-100000@lionking.org>

next in thread | previous in thread | raw e-mail | index | archive | help

Maybe this problem is related to the FIN_WAIT_2 problem encountered with
older releases of Apache. I'm no TCP expert and don't have the RFC in
mind, but if you run a newer Apache release (e.g. 1.3.1) then there
shouldn't be a problem.

http://www.apache.org/docs/misc/fin_wait_2.html discusses the problem. 

You didn't write, if your server is under heavy load or if the problem
occurs after many hits. Anything unusual in the logs?

Greetings,
                 Sascha

On Mon, 3 Aug 1998, Brian Tiemann wrote:

> 
> 	Okay-- so I've been able to fix the first part of my problem,
> thanks to the advice on this list-- that part was getting apache to spawn
> more than 128 or so total processes. However, I've got a new phenomenon
> happening; I hope someone can enlighten me:
> 
> 	Most of the time, my server sits at about 60 processes, 30 of
> which are httpd. However, every so often (every two days or so), the
> number of httpd processes will suddenly just start building up; old
> processes won't close, and I'll look and find 200 or 300 httpd processes
> sitting idle and not allowing any new ones to spawn.
> 
> 	The output of netstat shows that most of the dead connections are
> in the TIME_WAIT state; restarting httpd will kill the dead processes
> (they go zombie, and then the process leader kills them on the second or
> third round of kill signals), but the connections remain open in
> TIME_WAIT. Apache's server-info handler page shows that all the dead
> connections are still in the "W" (write) phase.
> 
> 	What's going on here? I don't want to have to keep running top to
> see whether the server's going haywire every few minutes. Here's my
> config, again, for the record:
> 
> kern.maxvnodes: 11907
> kern.maxproc: 4116
> kern.maxfiles: 8232
> kern.argmax: 65536
> kern.securelevel: -1
> kern.hostid: 0
> kern.clockrate: { hz = 100, tick = 10000, profhz = 1024, stathz = 128 }
> kern.posix1version: 199009
> kern.ngroups: 16
> kern.job_control: 1
> kern.saved_ids: 0
> kern.boottime: { sec = 900759813, usec = 736527 } Sat Jul 18 04:03:33 1998
> kern.domainname: 
> kern.update: 30
> kern.osreldate: 226000
> kern.bootfile: /kernel
> kern.maxfilesperproc: 8232
> kern.maxprocperuid: 4115
> kern.dumpdev: { major = 255, minor = -65281 }
> kern.somaxconn: 256
> kern.maxsockbuf: 262144
> kern.ps_strings: -272637968
> kern.usrstack: -272637952
> kern.shutdown_timeout: 120
> kern.acct_suspend: 2
> kern.acct_resume: 4
> kern.acct_chkfreq: 15
> kern.quantum: 10
> kern.sockbuf_waste_factor: 8
> kern.consmute: 0
> 
> 	And, in login.conf:
> 
> www:\
>         :path=/bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin:\
>         :cputime=infinity:\
>         :filesize=128M:\
>         :datasize-cur=64M:\ 
>         :stacksize-cur=32M:\
>         :coredumpsize-cur=0:\
>         :maxmemorysize-cur=128M:\
>         :memorylocked=32M:\ 
>         :maxproc=512:\
>         :openfiles=512:\ 
>         :tc=default:
> 
> 
> 	Can anyone offer some suggestions? Thanks very much!
> 
> Brian
> 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-questions" in the body of the message
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.96.980803142953.11763C-100000>