You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apache-bugdb@apache.org by Dean Gaudet <dg...@arctic.org> on 1998/06/17 20:30:01 UTC
Re: general/2452: httpd eats all CPU!! - critical problem (fwd)
The following reply was made to PR general/2452; it has been noted by GNATS.
From: Dean Gaudet <dg...@arctic.org>
To: apbugs@apache.org
Cc: Subject: Re: general/2452: httpd eats all CPU!! - critical problem (fwd)
Date: Wed, 17 Jun 1998 11:39:09 -0700 (PDT)
---------- Forwarded message ----------
Date: Wed, 17 Jun 1998 20:05:53 +0200
To: Dean Gaudet <dg...@arctic.org>
Cc: Rainer.Scherg@rexroth.de
Subject: Re: general/2452: httpd eats all CPU!! - critical problem
From: Rainer Scherg <Ra...@t-online.de>
Dean Gaudet schrieb:
>
> Is your ServerRoot on NFS? If so try using the LockFile directive.
>
Hello!
Sorry - No, the filesystem is on an internal harddisk (no remote mounts
for webserver directories)...
To keep it short, a list what I've tried or I'm still doing to track
down the problem:
- Checked all(?) hints on the apache bugdb & dejanews (done)
- Performance hints from the FAQ (done and still doing)
- Checked the configs (done some tune up)
- Track down the problem using "truss" and "lsof" (still working on)
- Tried to alter the apache code (insert debug code)
no luck so far...
We are using the apache for intranet servers and as virtual intranet
(all servers are virtual)
proxy1 = intranet proxy, proxy2 = authentification proxy for internet
firewall
But as far as I can say at this moment, the problem seems to be located
in the proxy functionality.
Apache is fast in serving intranet pages (own pages).
Requests for web pages via the proxies seems to be too slow (compared to
a direct access to
the firewall proxy).
It seems to me very odd, that apache (10 active, 3 idle) can spiral down
a Sparc 1000 (3 CPUs,
512 MB, > 50 GB HD).
At this moment we'll bind apache to only one cpu (pbind -cmd), so that
the server will not be
totally jammed - but this is no solution.
I'm still trying to track down the problem, any ideas how it nailed
down?
Tnx for help! - Rainer