Re: Problem with memory management
| From: | Nathan Rixham | Date: | Fri, 10 Oct 2008 19:32:54 +0000 |
| Subject: | Re: Problem with memory management | ||
| References: | 1 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-281692@lists.php.net to get a copy of this message | ||
Alan Boudreault wrote:
Hi all, I'm wondering why PHP doesn't free my memory with this test code. The memory usage is always the same even if i unset my object. The Garbage collector seems to only free the memory at the end of the script. Here's the php Scripts that i use for testing: <?php //dl("php_mapscript.so"); function test() { $oShapeFile = ms_newShapefileObj(interesting, I'm finding the same thing in one of my atom feed parsers; over time no matter how much I unset / truncate variables the memory usage stills grows over time - at this time I can't find any way to bring it right down; on a timer the whole script resets and restarts itself; one thing I have noticed is that I can see the emalloc memory usage report dropping and rising [memory_get_usage( false );], but still rising over time.. hope this wasn't a hijack; just here trying to figure out the same problem at the minute! Regards.. Nathan"/opt/www/bdga/msp/data/bdga/BDGA_HYDRO_S_POLY.shp", -1); echo "before getShape : ".memory_get_usage(true)."\n"; for ($i=0; $i<$oShapeFile->numshapes;$i++) { $oShape = $oShapeFile->getShape($i); $oShape->free(); unset($oShape); $oShape = NULL;} echo "after getShape : ".memory_get_usage(true)."\n"; $oShapeFile->free(); unset($oShapeFile); $oShapeFile = null;echo "after free : ".memory_get_usage(true)."\n";} echo "start : ".memory_get_usage(true)."\n"; test(); echo "end : ".memory_get_usage(true)."\n"; ?> Output result: start : 262144 before getShape : 262144 after getShape : 11010048after free : 11010048end : 11010048 I've also run valgrind to be sure that is not my extension that doesn't free its memory: $ valgrind --leak-check=full php -f shapeTest.php ==18730== LEAK SUMMARY:==18730== definitely lost: 0 bytes in 0 blocks. ==18730== possibly lost: 0 bytes in 0 blocks. ==18730== still reachable: 240 bytes in 2 blocks. ==18730== suppressed: 0 bytes in 0 blocks.Thanks, Alan