Hello,
I have also been experiencing the same problem with PHP 4.0.6.
A httpd process will start taking over 99% of the CPU on my
SMP processor on RH 7.2, Apache 1.3.20 (standard RH RPM)
when I run some complex scripts with apachebench:
ab -n1000 -c20 http://url/to/php/script/gone/crazy.php
These scripts are accessing Oracle (oci8). I thought it might
be some bottleneck in the configuration so I checked my Oracle
sessions and they are ok (I am using non-persistent connections).
Memory usage is stable at about 11 Mb max for the greedy httpd
process.
The only other thing that i can think of that might be a
bottleneck is the "mm" session handler...
I remember having problems previously with the "file" session
handler because my benchmarks caused the /tmp directory to
and /tmp ran out of hard disk space (!) and am wondering whether this
could happen with "mm". Incidentally the SMP monster has 1 Gig of
RAM, and I have always have more than 400Mb free memory even
with my most stringent benchmarks that are causing problems.
Are there any constants in shared memory or "mm" source code
that I can tweak?
Another point is that some simpler PHP scripts accessing Oracle
and sessions do not cause these problems. I can bang away with
ab -n4000 -c40 http://url/to/simpler/script.php
with no problems.
I will test with 4.1.0 next week when I get back to the office.
-- John Lim
<tauren@servlets.net> wrote in message news:bug-14333@bugs.php.net...> From: tauren@servlets.net> Operating system: RH 6.2 SMP> PHP version: 4.0.6> PHP Bug Type: Apache related> Bug description: Apache processes consume all CPU>> I've been experiencing the exact same problem that is described in bug> #14290 and #8446 for quite some time now but did not know which Apache> module was causing it. Up until now, I've had a cron job that simply
kills
> off (with a -9) any httpd processes that are using 99% or more cpu time.>> Today I've been trying to track down what exactly is causing the problem.> I've eliminated all extra Apache modules and did not experience the> problem. When I added PHP back in, the problem started immediately.> Within one minute of starting Apache back up, the high-CPU processes> started appearing again.>> The Apache "server-status" didn't indicate that ANY php script had been> hit. The processes just start going out of control after some time. In> fact, there isn't even a single *.php* file on the server. I really don't> think this is happening because of a PHP script being run.>> I'm currently testing this out on a Red Hat 6.2 Linux (SMP) box with dual> CPUs. From the sound of things in the other bug reports (#14290 and> #8446), the problem only seems to be happening on SMP servers. I did not> compile with any extra PHP modules except for the core PHP 4.0.6.>> I haven't really done a lot with PHP, so I'm not sure how to help debug> this problem. But I do want a stable Apache environment with PHP support> for my hosting customers. If there is anything I can do to help debug> things, please let me know.>> I've read the page on using gdb, but I'm think this is a different kind of> situation. Apache isn't crashing, but certain processes are going> "out-of-control". Is there a way to get a backtrace of a particular> process while it is still running?>> Until this problem can be resolved, I'm going to have to remove PHP from
my
> servers. I really don't want to have to do this, but the instabilities
are
> becoming too much to handle and very hard to explain to our customers.>> Please let me know what I can do to help debug and solve this problem.>> Thanks!> Tauren>>> --> Edit bug report at: http://bugs.php.net/?id=14333&edit=1>