ID: 19529
Comment by: erik@gavert.net
Reported By: sroussey@network54.com
Status: Open
Bug Type: MySQL related
Operating System: Linux 2.4.18
PHP Version: 4.2.3
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2002-10-01 19:36:44] sroussey@network54.com
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] sroussey@network54.com
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.
------------------------------------------------------------------------
[2002-10-01 12:10:20] sroussey@network54.com
Last thing! I do not use transactions or any transactional table
handlers. Just plain MySQL with MySQL table types.
------------------------------------------------------------------------
[2002-10-01 11:44:41] sroussey@network54.com
Sorry to reopen. I think it was changed to Bogus because of MySQL 4
usage. However, I use 3.23.49a for the server and use the built-in
client software that comes with PHP 4.2.3. Other users see the same
errors with 4.0.x servers.
Essentially this is a client PHP issue.
I am now logging all mysql errors to a file so I can see how different
changes affect things. As far as I can see, this condition only happens
under high load and only when using pconnect.
Again, nothing to do with MySQL 4.
------------------------------------------------------------------------
[2002-09-22 08:47:09] joc@presence-pc.com
I agree MySQL 4.x is still in beta quality (although it works quite
well), but before upgrading to php 4.2.1 I had strictly no problem with
PHP / MySQL 4.x (and I'm using MySQL 4.x libs).
------------------------------------------------------------------------
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