php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #11344 Memory not being reused.
Submitted: 2001-06-08 00:52 UTC Modified: 2001-06-21 16:34 UTC
From: brianlmoon@php.net Assigned:
Status: Closed Package: Scripting Engine problem
PHP Version: 4.0 Latest CVS (2001-06-08) OS: Linux
Private report: No CVE-ID: None
 [2001-06-08 00:52 UTC] brianlmoon@php.net
This is a follow up of sorts to: http://www.php.net/bugs.php?id=8889

I have been running some tests that do simple things to see what happens with the memory PHP uses in scripts.

The simplest of these tests was a page with no PHP on it other than the code that logged the process memory usage:

$PHP_PID = exec("echo \$PPID");
$fp=fopen("/www/logs/user_log.20010607", "a");
fputs($fp, "memusage\t$PHP_PID,".exec("ps -v -p $PHP_PID | awk '{print $8}'").",".time().",$HTTP_HOST,$REQUEST_URI\n");
fclose($fp);

I got interesting results.  Although the growth of the process was small, it was obvoius that the memory was growing.  Here is some sample data:

PID  MEM  TIME
3019 3272 991952835
3019 3420 991952835
3019 3428 991952836
3019 3448 991952836
3019 3480 991952837
3019 3488 991952838
3019 3500 991952839
3019 3504 991952840
3019 3516 991952899
3019 3520 991952843
3019 3520 991952844
3019 3524 991952847
3019 3524 991952851
3019 3524 991952854
3019 3524 991952858
3019 3524 991952862
3019 3532 991952868
3019 3532 991952910
3019 3544 991952879
3019 3552 991952888

As I said it is not a large growth, but it is there.

Now here is a script that creates an array over and over:

for($x=0;$x<1000;$x++){
    $arr[]=str_repeat("r", $x);
}

plus the code above that writes the log.  Here are the results:

PID  MEM  TIME
7322 3272 991953793
7322 3420 991953794
7322 3428 991953794
7322 3448 991953795
7322 3480 991953796
7322 3488 991953797
7322 3500 991953797
7322 3504 991953799
7322 3520 991953800
7322 3520 991953804
7322 3524 991953806
7322 3524 991953808
7322 3524 991953813
7322 3524 991953816
7322 3524 991953820
7322 3532 991953825
7322 3544 991953832
7322 3568 991953851
7322 3572 991953841
7322 3584 991953862


Again, a gradual growth occurs.  Now, we put this into our production environment where we are running applications and we end up with:

PID    MEM    TIME
31655  2656   991953822
31655  3124   991953826
31655  4012   991953833
31655  4560   991953839
31655  4956   991953858
31655  5020   991953877
31655  5256   991953879
31655  5312   991953880
31655  5348   991953889
31655  5900   991953903
31655  6132   991953904
31655  6392   991953904
31655  6664   991953917
31655  6944   991953933
31655  7204   991953938
31655  7256   991953940
31655  7556   991953941
31655  8404   991953943
31655  8548   991953950
31655  8692   991953968
31655  8880   991953976
31655  8880   991953981
31655  9148   991953990
31655  9400   991953992
31655  9608   991953994
31655  9608   991954006
31655  9788   991954021
31655  10156  991954023
31655  10424  991954029

Is there any explanation for any of this?  I can live with PHP keeping and REUSING memory, but I don't want to have to think about how much memory my scripts take up because it never gets a)reused or b) returned to the system.  If I wanted to worry about that stuff I would write in Perl or C.

Brian.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-06-15 06:57 UTC] zeev@php.net
Could you try to build PHP with fast_cache disabled and see what happens?

Edit Zend/zend_fast_cache.h, and change
# define ZEND_ENABLE_FAST_CACHE 1
to
# define ZEND_ENABLE_FAST_CACHE 0

 [2001-06-18 10:18 UTC] kalowsky@php.net
marking this as feedback until reporter responds....
 [2001-06-19 14:05 UTC] andi@php.net
Brian,

Can you please checkout the latest CVS of PHP&Zend and let us know if this problem is fixed now?
Thanks.
 [2001-06-21 16:34 UTC] brianlmoon@php.net
This is fixed in 4.0.6.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 01:01:28 2024 UTC