Hi Ivan and Dan (and the lists),
>The size of apache processes is telling me you're using PHP or some
other heavy apache module.
Indeed I am (I forgot to mention this). It is PHP 4.4.6, and it is
set up as an Apache module.
> If so, you can switch to using PHP as FastCGI responder via
mod_fcgid. The benefits are that you'll get only a few number of
> large php-cgi processes (configurable, usually around 10), and the
rest will be lighter httpd processes for serving static
Will that not have some other downsides? I remember that previously
when running PHP on the CGI, that e.g. a lot of debugging power got
lost, as each and every error would simply either return a blank
page, or simply an "internal servor error 500" or so.... Is that also
the case with FastCGI?
>BUT, if something else changed when you switched to the new apache
(e.g. PHP version, your web applications), it may not be
The PHP version got upgraded from 4.4.0 to 4.4.6 too, but none of the
actual application scripts changed.
BTW: At times what one sees happening is that 2 of the httpd daemons
quickly go up to (each, or in turn) about 50% (or 70% if it can grab
that much), then stays quite a while at that, and then goes back to a
more reasonable amount.
At other times, there are around 10+ httpd processes that each
consume around 5% of the CPU, with a lot more of them using around
0-1% of the CPU (perhaps defunct already?). Dunno. Apache + PHP is
lightning fast, but... at the expense of the CPU being pulled close
to 100% all to easily...
Then, regarding Dan's sendmail configuration suggestion: tnx! I just
put that in place and will monitor sendmail's behaviour today, to see
how it performs during heavy server load.
I'll let you guys know how I get on with this...
Meanwhile: I'm still open for suggestions as to how to best make
Apache behave less selfishly.
email@example.com mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"