Diagnosing Memory Leaks - Allowed memory size of # bytes exhausted

0 votes
asked May 11, 2009 by mike-b

I've encountered the dreaded error-message, possibly through-painstaking effort, PHP has run out of memory:

Allowed memory size of #### bytes exhausted (tried to allocate #### bytes) in file.php on line 123

Increasing the limit

If you know what you're doing and want to increase the limit see memory_limit:

ini_set('memory_limit', '16M');
ini_set('memory_limit', -1); // no limit

Beware! You may only be solving the symptom and not the problem!

Diagnosing the leak:

The error message points to a line withing a loop that I believe to be leaking, or needlessly-accumulating, memory. I've printed memory_get_usage() statements at the end of each iteration and can see the number slowly grow until it reaches the limit:

foreach ($users as $user) {
    $task = new Task;
    $task->run($user);
    unset($task); // Free the variable in an attempt to recover memory
    print memory_get_usage(true); // increases over time
}

For the purposes of this question let's assume the worst spaghetti code imaginable is hiding in global-scope somewhere in $user or Task.

What tools, PHP tricks, or debugging voodoo can help me find and fix the problem?

12 Answers

0 votes
answered Jan 12, 2009 by bart-van-heukelom

If what you say about PHP only doing GC after a function is true, you could wrap the loop's contents inside a function as a workaround/experiment.

0 votes
answered May 11, 2009 by kingoleg

There are several possible points of memory leaking in php:

  • php itself
  • php extension
  • php library you use
  • your php code

It is quite hard to find and fix the first 3 without deep reverse engineering or php source code knowledge. For the last one you can use binary search for memory leaking code with memory_get_usage

0 votes
answered May 11, 2009 by troelskn

PHP doesn't have a garbage collector. It uses reference counting to manage memory. Thus, the most common source of memory leaks are cyclic references and global variables. If you use a framework, you'll have a lot of code to trawl through to find it, I'm afraid. The simplest instrument is to selectively place calls to memory_get_usage and narrow it down to where the code leaks. You can also use xdebug to create a trace of the code. Run the code with execution traces and show_mem_delta.

0 votes
answered May 15, 2009 by patcoll

I noticed one time in an old script that PHP would maintain the "as" variable as in scope even after my foreach loop. For example,

foreach($users as $user){
  $user->doSomething();
}
var_dump($user); // would output the data from the last $user 

I'm not sure if future PHP versions fixed this or not since I've seen it. If this is the case, you could unset($user) after the doSomething() line to clear it from memory. YMMV.

0 votes
answered May 20, 2010 by nate-flink

I recently ran into this problem on an application, under what I gather to be similar circumstances. A script that runs in PHP's cli that loops over many iterations. My script depends on several underlying libraries. I suspect a particular library is the cause and I spent several hours in vain trying to add appropriate destruct methods to it's classes to no avail. Faced with a lengthy conversion process to a different library (which could turn out to have the same problems) I came up with a crude work around for the problem in my case.

In my situation, on a linux cli, I was looping over a bunch of user records and for each one of them creating a new instance of several classes I created. I decided to try creating the new instances of the classes using PHP's exec method so that those process would run in a "new thread". Here is a really basic sample of what I am referring to:

foreach ($ids as $id) {
   $lines=array();
   exec("php ./path/to/my/classes.php $id", $lines);
   foreach ($lines as $line) { echo $line."\n"; } //display some output
}

Obviously this approach has limitations, and one needs to be aware of the dangers of this, as it would be easy to create a rabbit job, however in some rare cases it might help get over a tough spot, until a better fix could be found, as in my case.

0 votes
answered Jan 7, 2011 by kosgei

I would suggest you check the php manual or add the gc_enable() function to collect the garbage... That is the memory leaks dont affect how your code runs.

PS: php has a garbage collector gc_enable() that takes no arguments.

0 votes
answered Jan 11, 2011 by xeoncross

I recently noticed that PHP 5.3 lambda functions leave extra memory used when they are removed.

for ($i = 0; $i < 1000; $i++)
{
    //$log = new Log;
    $log = function() { return new Log; };
    //unset($log);
}

I'm not sure why, but it seems to take an extra 250 bytes each lambda even after the function is removed.

0 votes
answered May 20, 2011 by gunnar-lium

I came across the same problem, and my solution was to replace foreach with a regular for. I'm not sure about the specifics, but it seems like foreach creates a copy (or somehow a new reference) to the object. Using a regular for loop, you access the item directly.

0 votes
answered Jan 5, 2012 by fronzee

I'm a little late to this conversation but I'll share something pertinent to Zend Framework.

I had a memory leak problem after installing php 5.3.8 (using phpfarm) to work with a ZF app that was developed with php 5.2.9. I discovered that the memory leak was being triggered in Apache's httpd.conf file, in my virtual host definition, where it says SetEnv APPLICATION_ENV "development". After commenting this line out, the memory leaks stopped. I'm trying to come up with an inline workaround in my php script (mainly by defining it manually in the main index.php file).

0 votes
answered Jan 22, 2012 by andy

One huge problem I had was by using create_function. Like in lambda functions, it leaves the generated temporary name in memory.

Another cause of memory leaks (in case of Zend Framework) is the Zend_Db_Profiler. Make sure that is disabled if you run scripts under Zend Framework. For example I had in my application.ini the folowing:

resources.db.profiler.enabled    = true
resources.db.profiler.class      = Zend_Db_Profiler_Firebug

Running approximately 25.000 queries + loads of processing before that, brought the memory to a nice 128Mb (My max memory limit).

By just setting:

resources.db.profiler.enabled    = false

it was enough to keep it under 20 Mb

And this script was running in CLI, but it was instantiating the Zend_Application and running the Bootstrap, so it used the "development" config.

It really helped running the script with xDebug profiling

Welcome to Q&A, where you can ask questions and receive answers from other members of the community.
Website Online Counter

...