From: mplomer at gmx dot de
Operating system: Windows, ev. Linux
PHP version: 5.2.3
PHP Bug Type: *General Issues
Bug description: Persistent memory consumption
Description:
------------
When using php arrays with a lot of entries (about 200000), I figured out
the following problem: PHP sometimes doesn't free all used memory after
completing the request. Apache uses under some circumstances 20-30 MB more
RAM after the request. The problem is that this happens per child. If an
Apache runs with 64 threads, it is possible, that httpd.exe consumes
persistently 300-600 MB of RAM, even without any active request.
Reproduce environment:
- I tested it under an Apache (1.3 and 2.2) environment unter Windows (XP)
(I didn't test it under Linux yet)
- Used PHP-Version: 5.2.3 - the problem was introduced with PHP 5.2. With
PHP 5.1.6 the problem does not appear (but I noticed, that PHP 5.1.6's
memory management is much slower than the new one :-)
- Set ThreadsPerChild to 1 in httpd.conf to make sure, you hit always the
same PHP instance and avoid any constraints
Reproduce procedure:
- Freshly start your 1-thread-Apache [It will consume about 10 MB]
- Execute the following script [Memory usage will grow to ~50-60 MB, and
after execution memory usage shrinks back to ~10 MB again ... works fine so
long]
- Execute the script again 2 or more times [... and surprisingly Apache
consumes about 35MB after the request is complete!] (The number of
executions you need to reproduce the problem depends on the elementCount of
the test-array, and eventually some system dependent factors; see reproduce
code)
- If you excecute the script some more times again, someimes the memory is
freed and memory usage is about 10MB again, but after some further
requests, the memory is NOT freed again.
Because of the last point, I think, it is not a memory leak. I also
compiled PHP as debug version and there where no memory leaks reported
(with report_memleaks = On).
But I still think, the consumed memory should be completely freed after
_each_ request. If this is a feature, because something is cached, it
requires a maximum of the cache size. 20-30MB per child is definitely too
much.
If you put an "echo memory_get_peak_usage(true);" at the beginning of the
script, you will see, that PHP claims to use only about 200-300 KB at every
script start time. It doesn't report the 20-30MB that it consumes since the
last execution.
I tested this with an array, but the problem can, of course, be deeper in
the new memory management of PHP 5.2
Reproduce code:
---------------
<?php
// elementCount: Count of elements which are created in the test array:
// - a count of 200000 demonstrates the problem at best on my machine
// - a count of 100000 or lesser reproduces the problem too, but you
need more
// calls of the script (browser refreshes) until the problem occurs
// - with a count of 400000 or more I couldn't reproduce the problem,
// there it works fine
// I couldn't figure out exactly, on which factors this count depends
on, but
// it _seems_ to be not machine dependent, but play around with it.
// Note also, that the count of array elements is important, not the
// size of their keys or values.
$elementCount = 200000;
for ($i = 0; $i < $elementCount; $i++) {
$variables[$i] = 'x';
}
// Even when you unset each array-element manually, the problem occurs
...
//for ($i = 0; $i < $elementCount; $i++) {
// unset($variables[$i]);
//}
// ... and/or if you unset the array itself ...
//unset($variables);
// ... but it does not occur, when you put the unset directly in the
first
// for-loop, that the variable will be unset immediately. Only a small
amount
// of memory is required for the whole request - so PHP can't forgot to
free
// many memory.
?>
Expected result:
----------------
see "Description": All memory being freed after execution of a PHP script.
Actual result:
--------------
see "Description": Not all memory is freed under some circumstances after
script execution.
--
Edit bug report at http://bugs.php.net/?id=41713&edit=1
--
Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41713&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41713&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41713&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41713&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=41713&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41713&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=41713&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=41713&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41713&r=support
Expected behavior: http://bugs.php.net/fix.php?id=41713&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=41713&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=41713&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41713&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41713&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41713&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=41713&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41713&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41713&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41713&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=41713&r=mysqlcfg