ID: 19529
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: MySQL related
Operating System: Linux 2.4.18
PHP Version: 4.2.3
New Comment:
What happens is that the mysql connection that gets the problem is
locked up. It won't ever work again.
After a while all of our mysql connections showed the problem making
the site completely unusable. As of v4.2.3 php does a ROLLBACK each
time connection is re-used. ROLLBACKS will give an error if updates
have been done on a MyISAM table, I have removed that query now. Will
see if that solves it.
It looks like all us are running quite many queries per second? I see
the problem on a site running 60+ queries per second.
Previous Comments:
------------------------------------------------------------------------
[2002-10-06 08:13:00] [EMAIL PROTECTED]
Another note: [EMAIL PROTECTED] states that the problem seems to
only happen at high load, and is intermittent. In my experience, it
seems to happen after long periods of running. More specifically, my
(production) system will run fine for hours with 30+ queries/second,
and then suddenly start having several of the "Commands out of sync"
error messages per second. They are still intermittent (ie. they don't
appear at every query), but these symptoms seem to indicate a memory
leak or other delayed-impact bug as the cause of the problems.
------------------------------------------------------------------------
[2002-10-06 07:21:37] [EMAIL PROTECTED]
I'm having the same problem; it appears to have started when I upgraded
PHP from 4.2.2 to 4.2.3. At the same time, I upgraded Apache from
1.3.26 to 1.3.27. I wasn't using the built-in client lib, but have
switched to it now... although after reading the comments here, I don't
expect that to fix things.
I'd just like to emphasize that I'm experiencing this bug using stable
versions of both Apache (1.3.27) and MySQL (3.23.44). PHP definitely
seems to be the culprit.
------------------------------------------------------------------------
[2002-10-05 14:51:46] [EMAIL PROTECTED]
I'm having this problem also.
I replaced all pconnects with connect, this makes thing work.
But the httpd processes are leaking alot of memory. Had to restart
httpd after a while when it was using 900MB swap.
It looks like php is not correctly freeing query memory when there are
still rows left to fetch.
I'm running mysql 4.0.4, it was working well until I upgraded the php
to 4.2.3. I have tried with both the built in mysql client lib and the
4.0.4 one.
------------------------------------------------------------------------
[2002-10-01 19:36:44] [EMAIL PROTECTED]
Last data point: the workaround in my last message works with 3.23.x
but not 4.0.x as far as I can tell. Here is my test matrix:
PHP client using built-in mysql libs.
Server: 3.23.49a 4.0.2
-------- ----
connect OK OK
pconnect fail fail
pconnect OK fail
w/ fix
------------------------------------------------------------------------
[2002-10-01 12:52:12] [EMAIL PROTECTED]
I have been looking through CVS log at lxr.php.net to see what has
changed in mysql support in PHP this last year. One change was the
inclusion of mysql.connect_timeout.
In the docs it says the default is 0. This is backed up by the
default:
496 mysql_globals->connect_timeout = 0;
However, I expected the line:
352 STD_PHP_INI_ENTRY_EX("mysql.connect_timeout","",...
to have ("mysql.connect_timeout","0",
Also, things seem odd to me:
651 if (connect_timeout != -1)
749 if (connect_timeout != -1)
Why is it checking for the connect_timeout as to -1 rather than zero? I
think telling mysql that the connect timeout is zero causes the
problems: the connection closes really quick! Well, it seems to be a
race condition anyhow. As a default. Ick. And exploited by the time the
connect is reused.
I set mysql.connect_timeout = -1 in the .ini file as a temp workaround.
Seems to be working. I will wait a day and report if this indeed
eliminates these errors.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/19529
--
Edit this bug report at http://bugs.php.net/?id=19529&edit=1
