Hi
I am back in the office and have confirmed that with PHP 4.0.6, the 99% cpu bug only occurs with "mm". With the "files" session handler it doesn't happen. This was on the SMP server with the given config below... Bye, John John Lim <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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]
