Bug #14053 Updated: Memory leak when using BIG array (>160MBytes)
| From: | ingo dot bez at in-systeme dot de | Date: | Fri, 16 Nov 2001 07:46:00 +0000 |
| Subject: | Bug #14053 Updated: Memory leak when using BIG array (>160MBytes) | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-70622@lists.php.net to get a copy of this message | ||
ID: 14053
User updated by: ingo.bez@in-systeme.de
Reported By: ingo.bez@in-systeme.de
Old Status: Feedback
Status: Closed
Bug Type: Reproducible crash
Operating System: Linux (2.2.x/2.4.x)
PHP Version: 4.0.6
New Comment:
Hi, hholzgra!
Thanks a lot - this one marks the spot.
And: PHP _IS_ the right tool for the job. (The scenario, which eats the memory just happens once
within a thousand requests so it's "worth" the pain).
The apache just freezes that very process (the script took over) for about 5 Minutes - which will
not bother me ether, because of another 49 processes are idling in the background.
Thank you all.
Previous Comments:
------------------------------------------------------------------------
[2001-11-15 07:37:08] hholzgra@php.net
memory once requested by php or apache
is not given back to the operating system
when being freed, its just available for
reuse *within* the process
(won't discuss any further here ...)
and the CPU use you see is a result of
the Zend engine cleaning up the complete
array element by element, including
reference count handling and variable
destructor calls
i don't know if this could be optimized,
but this is not a bug, PHP is just not the
right tool for the kind of job you want
it to do here
so the only bug in your report is the freeze
if the apache process realy doesn't respond
anymore. are you sure that it is dead and
that it is not just getting no requests
served as the sceduler preferes other processes
from the apache process farm as they haven't
used as much resources (esp. CPU-time) yet?
------------------------------------------------------------------------
[2001-11-15 07:02:16] ingo.bez@in-systeme.de
Hi!
We accumulate approx. 60,000 datasets with 12 columns in the array and manipulate nearly half of the
fields before we put them back into the db.
Ingo
------------------------------------------------------------------------
[2001-11-15 06:51:09] sniper@php.net
It would help also to know which database is this and
if you have some sort of short example script to add here
too.
------------------------------------------------------------------------
[2001-11-15 05:17:50] derick@php.net
How many elements are there in the array? And isn't there another way to do this?
Derick
------------------------------------------------------------------------
[2001-11-14 10:47:48] ingo.bez@in-systeme.de
We do query a database and put the fetched result into some array, whichs keys are the first field
of the fetched result-row. No problem to get the array build, it eats up about 180MBytes from the
2GBytes RAM the server has.
The script works fine, does some manipulation in the array (strings, ints) and re-inserts it into
the database.
After the script terminates - all output to the browser is done - the Apache-process responsible for
that request won't free the acquired memory. It instead eats one CPU completely for about
3-5minutes and then freezes - with aprox. 180MBytes of reserved RAM. (Fire the request 10 times and
be sure to have the swap working!)
We currently use:
- HP LC2000r (2*PIII 933MHz, 2GByte RAM, 18GB HDD)
- Linux (Slackware 8.0), glibc2.2.3, Kernel 2.4.13 SMP
- Apache 1.3.22
- PHP 4.0.6
- ZendOptimizer 1.1.0.
Tested and reproduced with:
- Apache 1.3.20, 1.3.17
- w/o ZendOptimizer.
- PHP4.2.0-dev
It'll be nice to hear from you!
Thanks in advance,
Ingo Bez
------------------------------------------------------------------------
Edit this bug report at http://bugs.php.net/?id=14053&edit=1