On Fri, 12 Sep 1997 [EMAIL PROTECTED] wrote:
> Synopsis: Runaway httpd process under heavy load
>
> State-Changed-From-To: open-analyzed
> State-Changed-By: dgaudet
> State-Changed-When: Fri Sep 12 22:33:39 PDT 1997
> State-Changed-Why:
> Yeah this is a sensable way to defend against this problem.
> It's odd though, my development platform is an SMP davem-2.0.31-pre2
> kernel ... and I've pushed it up over 700 req/s, and never
> seen this. But we've had a dozen reports about it, so we
> should work around it. I've submitted a patch for
> consideration.
FWIW - I went ahead and changed the continue; to exit(0); and it immediately
cleaned the problem out. In fact, I've changed it on other machines with the
same problem and -blip- gone, no more lockies.
It has to be a kernel problem. I haven't had a chance to dig around in the
code for the source (more interested in just getting the thing fixed!) I'm
currently running 2.0.29 and 2.0.30 on a combination of p5's and p6's.
Possibly related item: I've noticed that, on some machines, the main process
is only able to fork off 240-250 (probably a limit of 255) children before
being unable to continue. It seems an rlimit problem of some sort (even
though I've looked at the apache code which rlimits and it SHOULD be fine).
Symptoms are 'cannot spawn child process' when running CGIs.
Workaround: Run apache in a csh with 'maxproc 1024'. Tried this and it works
dandy. If there's something glaringly obvious that I've missed in the apache
config about children spawning, please accept my in-advance apology for being
blind. ;)
---
__________________________________________
| |
| Rick Franchuk - TranSpecT Consulting |
|_______ _______|
\mailto:[EMAIL PROTECTED]/
