php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #14053 Memory leak when using BIG array (>160MBytes)
Submitted: 2001-11-14 10:47 UTC Modified: 2001-11-16 02:46 UTC
From: ingo dot bez at in-systeme dot de Assigned:
Status: Closed Package: Reproducible crash
PHP Version: 4.0.6 OS: Linux (2.2.x/2.4.x)
Private report: No CVE-ID: None
View Developer Edit
 [2001-11-14 10:47 UTC] ingo dot bez at in-systeme dot 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

Patches

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-11-15 05:17 UTC] derick@php.net 
How many elements are there in the array? And isn't there another way to do this?

Derick
 [2001-11-15 06:51 UTC] 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 07:02 UTC] ingo dot bez at in-systeme dot 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 07:37 UTC] 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-16 02:46 UTC] ingo dot bez at in-systeme dot de 
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Sep 07 21:01:27 2024 UTC