RE: [PHP] Re: php-general Digest 19 Oct 2000 07:34:18 -0000 Issue295

Dan- We use PHP in a very large and complicated application yet we saw only performance improvements in moving from version 3 to 4. We did see a similar problem to what you described: > reports from my database I am moving back to php3. Also I have seen weird > things on the freebsd machine like ....doing a killall httpd does not kill > the deamon. At one point even a kill -9 on the pid would not work and I This ended up being a code problem which only happened under a very specific set of circumstances and only showed itself in PHP4 (by causing the Apache process to baloon up in usage of CPU and memory). The move to the Zend engine may have lowered some of the tolerances, but the problem itself was still due to a programmatic error in our code. Rasmus seems to have your problem pegged, but have you tried enabling debugging and looking at a backtrace? John On Mon, 6 Nov 2000, Dan Phoenix wrote: > > [Wed Oct 25 18:57:34 2000] [error] (54)Connection reset by > peer: getsockname > [Wed Oct 25 18:57:52 2000] [error] (54)Connection reset by > peer: getsockname > [Wed Oct 25 18:57:54 2000] [error] (54)Connection reset by > peer: getsockname > [Wed Oct 25 18:57:54 2000] [error] (54)Connection reset by > peer: getsockname > [Wed Oct 25 18:57:57 2000] [error] (54)Connection reset by > peer: getsockname > [Wed Oct 25 18:57:59 2000] [error] (54)Connection reset by > peer: getsockname > [Wed Oct 25 18:58:04 2000] [error] (54)Connection reset by > peer: getsockname > [Wed Oct 25 18:58:09 2000] [error] (54)Connection reset by > peer: getsockname > [Wed Oct 25 19:00:26 2000] [warn] child process 1394 still did not exit, > sending a SIGTERM > [Wed Oct 25 19:00:26 2000] [warn] child process 1395 still did not exit, > sending a SIGTERM > [Wed Oct 25 19:00:26 2000] [warn] child process 1396 still did not exit, > sending a SIGTERM > [Wed Oct 25 19:00:26 2000] [warn] child process 1397 still did not exit, > sending a SIGTERM > [Wed Oct 25 19:00:26 2000] [warn] child process 1398 still did not exit, > sending a SIGTERM > [Wed Oct 25 19:00:26 2000] [warn] child process 1399 still did not exit, > sending a SIGTERM > [Wed Oct 25 19:00:26 2000] [warn] child process 1400 still did not exit, > sending a SIGTERM > [Wed Oct 25 19:00:26 2000] [warn] child process 1401 still did not exit, > sending a SIGTERM > [Wed Oct 25 19:00:26 2000] [warn] child process 1402 still did not exit, > sending a SIGTERM > [Wed Oct 25 19:00:26 2000] [warn] child process 1403 still did not exit, > sending a SIGTERM > [Wed Oct 25 19:00:26 2000] [warn] child process 1404 still did not exit, > sending a SIGTERM > [Wed Oct 25 19:56:55 2000] [notice] Apache/1.3.12 (Unix) PHP/4.0.2 > configured -- resuming normal op > erations > tested this with..... PHP/4.0.2 amd php latest and apache latest also. > > > > httpd in free(): warning: recursive call. > httpd in free(): warning: recursive call. > httpd in free(): warning: recursive call. > httpd in free(): warning: recursive call. > > [Mon Nov 6 16:24:26 2000] [notice] child pid 9085 exit signal > Segmentation fault (11) > [Mon Nov 6 16:24:44 2000] [notice] child pid 11828 exit signal > Segmentation fault (11) > > that enough? > no > ok here is some more > [Mon Nov 6 13:40:20 2000] [notice] child pid 858 exit signal Segmentation > fault (11) > [Mon Nov 6 13:40:31 2000] [error] (32)Broken pipe: accept: (client > socket) > [Mon Nov 6 13:40:53 2000] [notice] child pid 29653 exit signal > Segmentation fault (11) > [Mon Nov 6 13:41:01 2000] [notice] child pid 1207 exit signal > Segmentation fault (11) > [Mon Nov 6 13:41:21 2000] [error] (32)Broken pipe: accept: (client > socket) > [Mon Nov 6 13:41:30 2000] [notice] child pid 28784 exit signal > Segmentation fault (11) > [Mon Nov 6 13:41:36 2000] [notice] child pid 1206 exit signal > Segmentation fault (11) > > these webservers have 250 megs of ram and 510 megs of swap. > ...at 150 maxclients.....all of it is gone and all of memory and swap is > eaten and system becomes unstable...php3 can handle 150 maxclients without > problems and persistant connections to mysql. I have tested it on linux > and freebsd...same result always. > I even went into php4 compile time options to compile limit-memory into > it...did not make a difference. For the reason that i cannot put php4 at > 150 maxclients under heavy load and the fact i am getting aborted connects > reports from my database I am moving back to php3. Also I have seen weird > things on the freebsd machine like ....doing a killall httpd does not kill > the deamon. At one point even a kill -9 on the pid would not work and I > had to reboot the machine. > > My config options for php4 were: > CFLAGS='-O2' ./configure --with-mysql=/usr/local/mysql > --with-gd=/usr/local/gd --enable-inline-optimization --with-gnu-ld > --with-apache=../apache_1.3.14 --enable-track-vars --disable-debug > --with-ttf --with-t1lib --with-config-file-path=/usr/local/apache > --with-curl=/usr/local/curl --enable-memory-limit > #make > #make install > > My config options for apache were > CC="gcc" OPTIM="-O2" ./configure --prefix=/usr/local/apache > --enable-module=rewrite --enable-shared=rewrite > --activate-module=src/modules/php4/libphp4.a --enable-module=php4 > > Got any more problems ...email me directly.... > If I still have not convinced you then you must have problems with being > stubborn :) Owww I'll leave you with some more evidence.... > a mysql table crashed....will bring a webserver to it's knees..... > and the cpu will go skyrocket. We are probably the biggest internet > website for running php on such a large scale---access logs are in the > gigabit range. So you tell me it works fine for you ...does not tell me > anything. I have not met any other site that gets as much traffic as us > running php....thx. Want more evidence....? I am done but yes I got more. > Getsockbyname errors are what exactly? Would seem to me a possible dns > issue....but then again not being able to kill of clients is completely > different. I do not recommend php4 for high volume sites....and noone I > know that gets alot of traffic went to php4 for this exact reason.... > > Thank-you for your time, > > Dan > > > On Tue, 7 Nov 2000, James Moore wrote: > > > Date: Tue, 7 Nov 2000 00:20:25 -0000 > > From: James Moore <jmoore@php.net> > > To: Php-General <php-general@lists.php.net>, > > Dan Phoenix <dphoenix@bravenet.com> > > Subject: RE: [PHP] Re: php-general Digest 19 Oct 2000 07:34:18 -0000 > > Issue295 > > > > > I doubt that...I got solid evidence to draw a case now. > > > Considering your a developer I expect what you said. > > > > I would be interested in seeing this evidence. I am not a developer, I help > > out with the QA and the Docs ;) Anyway I would argue that PHP 4 is as stable > > as PHP3 was due to the fact the code is cleaner and a lot of it was ported > > from PHP3 and the zend engine has been abstracted, there are some install > > problems that need fixing but that is being done, the majority of this is > > docu problems and helping people fix thier own problems rather than coming > > here or php-dev and calling them bugs. The bug database is the least crowded > > it has been for a long time and the uptake of php has grown. But if you have > > evidence to show that im wrong post it.. I would love to see it. > > > > > > > > On Tue, 7 Nov 2000, James Moore wrote: > > > > > > > Date: Tue, 7 Nov 2000 00:11:38 -0000 > > > > From: James Moore <jmoore@php.net> > > > > To: Dan Phoenix <dphoenix@bravenet.com> > > > > Subject: RE: [PHP] Re: php-general Digest 19 Oct 2000 07:34:18 -0000 > > > > Issue 295 > > > > > > > > > > > > > > > > > > Just so everyone knows...php4 just is not stable at all. > > > > > php3 can handle loads way better and uses way less resources. > > > > > THis has been tested over and over again. We get developers > > > blaming it on > > > > > mysql libraries etc....well then tell me how it worked so > > > well in 3 and > > > > > not in 4. > > > > > > > > > > Thank-you for your time....I agree php4 is great...for small sized > > > > > database companies. > > > > > > > > > > > > > Interesting opinion I think you might be on your own there... > > > > > > > > James > > > > > > > > > > > > > > -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org mQGiBDnCZ1oRBACFgkFCV6p3dWic1qm1FLhip5beIyzZSt+ccTDYQQdPZA/t5H+k PZ7ZFBIUrXz/oEqwQwlEKlg8JQqg7hgtcL+xrIJ0BInLeSJG4lvvB551g59Thr7/ OsdxNVxKci775+K+GkdAz4xcULMuB+QE7t665Ri46EAS8ALos5UG6DGmhwCguD0v 1cxwy/KlKr+oi4sWM9caueED/RmjiSD3vmBZQt6PMisVe1AmkEf6cJoemduCSJxu 0eMz/LIeu+CqfpuJH2N/dZ3hRj9xMSHF4l71wKqV99zhm58kDGwG1u3yVzULPDqz 0yL+8nunlkoOUyn3zOnh3Zmz4POFVMZQ5oian3QkLllUwly5JCi5tWULxZ2vOkb0 zzjuA/4jigNxYV4NAyCl+wAbnyzk9/Iz8EHv4/0Ex8ytlcMtvBJKa9HjJxlyIl74 yOILHk3+GSAdM0b3ZmbavpoCpebinOMBhqEVBwCI4VUIAqf86gx+2dKBGxfKPnU4 Xxvqs/BOl/EbeJjyd4uieYndGRaWg+kYXqZ7SxrlFN24fohnd7QgSm9obiBEb25h Z2hlciA8am9obkB3ZWJtZXRhLmNvbT6IVgQTEQIAFgUCOcJnWgQLCgQDAxUDAgMW AgECF4AACgkQIt6tVu6+jd3SHwCgjssFktMXf8NjE9JBR+sJ2gDIsW8An0CFNdFd dU+DJYC6ogYP9AsVfM27uQENBDnCZ2MQBAD8E0qe1gBKjtoRmyiyORtwhOz/2XZE mqiZN2NouAUWRRZd4dHggFAA1jUsp2MVIZZQyY9ajNVy3Oaxj5kYz8LR5GItxxcD jC8RFXKM40ZfTJeR7fH6eJa689w+le71Tt4ALyN4xcjSWuksr8795AhHFjonDi8D rgGIq6GtWvi/KwADBgQAmeBbcjPzhqR2M8TdvEyNfVTQSSp/RNoTjNNWpHui8V0p kiQ49tbsqeMjXGToGgMugfmrX77JidXyuVjgYjT9xUdaaA25qKAR75M9izDliT7Y h5L+QZTAw0/5X9go7XK3WI3LYfFrp4TP0veXgSWxDqccqsRzWKW7IoXsliTCbVqI RgQYEQIABgUCOcJnYwAKCRAi3q1W7r6N3YIcAKCkJMTPLu6tOPnXPl2s3xmnSawy BACeOx83WlBhVScYWo+BUzntJ6ks4T0= =OkJU -----END PGP PUBLIC KEY BLOCK-----