ID: 19796
User updated by: [EMAIL PROTECTED]
-Summary: Oracle query in array, returned by function: memory
leak + high CPU load
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Performance problem
Operating System: Digital Unix V4.0F
PHP Version: 4.2.3
New Comment:
What I'm wondering is wheter the memory is going to be given back to
the system if it needs it ? With 4.0.4pl1, the VSZ/RSS numbers were
above 150 M and never shrunk, which worried the system maintenance
staff. I know such memory readings have to be carefully interpreted but
it's still troubling...
Previous Comments:
------------------------------------------------------------------------
[2002-10-09 11:18:34] [EMAIL PROTECTED]
Does this 'latest' version fix some items that could be related to my
problems?
------------------------------------------------------------------------
[2002-10-09 09:38:30] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
------------------------------------------------------------------------
[2002-10-09 04:43:15] [EMAIL PROTECTED]
I have compiled PHP 4.2.3 (was 4.0.4pl1) and tested my code: the high
CPU load after code execution is no more there, but there is still
memory leak:
before:
nobody 19621 0.0 0.0 14.3M 560K ?? S 16:32:09 0:00.00
/www/bin/httpd
after:
nobody 19621 0.0 0.9 50.3M 37M ?? S 16:32:09 0:33.91
/www/bin/httpd
^^^^^ ^^^
If I comment out "$retval[$key][$col_name]= $value", then I have:
nobody 20871 0.0 0.0 14.8M 1.9M ?? S 17:24:49 0:00.03
/www/bin/httpd
------------------------------------------------------------------------
[2002-10-07 07:23:27] [EMAIL PROTECTED]
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP --
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.
------------------------------------------------------------------------
[2002-10-07 06:33:42] [EMAIL PROTECTED]
I need to generate some reports and I need to have some table's data as
a whole as some columns of a row in this table and other tables
reference other rows of this table. The PHP version is 4.0.4pl1, Apache
is 1.3.14, and Oracle 8.1.7.
So basically, I do this inside a function:
.
.
.
while (ora_fetch($cursor)) {
$key = ora_getcolumn($cursor, 0);
for ($j=0; $j<ora_numcols($cursor); $j++) {
$col_name=ora_columnname($cursor, $j);
$col_value = ora_getcolumn($cursor,$j);
$ret_array[$key][$col_name] = $col_value;
}
}
.
.
.
Here are my problems:
- after the end of the script execution, the CPU load (seen by top)
goes up to 99.90% for several minutes (for 4000 entries of 20 columns,
it lasts about 2 minutes); during the script execution and HTTP
transfer, the CPU load is normal, once the file transfer is over, the
load becomes 99.x %
- if I do this on a just started Apache, a lot of memory is consumed
(normal) but not released:
Before:
nobody 10159 0.0 0.1 14.8M 2.3M ?? S 14:42:45 0:00.25
/www/bin/httpd
After
nobody 10159 99.9 0.7 42.7M 29M ?? R 14:42:45 0:36.23
/www/bin/httpd
^^^^ CPU ^^^^ ^^^^^RAM
- I did some experiements and observed this:
- if I do an exit in the returning function just before "return
$ret_array", then the high CPU load does not occurs (I'm not sure about
memory leak)
- if now I do an exit just after calling the function, then the
high CPU load occurs (I'm not sure about memory leak). It looks like if
$ret_array "moves" out of the function, a high CPU load occurs... I
have tried with references, unset, etc... before/after calling the
function to help the garbage collection at the end of the script but it
doesn't help, I always have the high CPU load.
Do you have any idea of what's happening?
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=19796&edit=1
