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 <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > From: [EMAIL PROTECTED] > 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 > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
