I’d like to get everyone here focused on the same page by starting with some minor “education” …
A web application can’t have a memory leak per-se over the course of staying up or being run multiple times.
It is not like Asteirsk which is started up in a daemon and run continuously in the background thus having the ability to continuously consume memory. Once a page is loaded or an ajax request is fulfilled, which is technically no different from the server’s perspective, the application ends and all resources that it has requested are relinquished. During the course of a page load it may use a lot of memory but then it id finished.
So with this in mind it’s important to try and focus a bit more on WHAT is actually leaking memory, WHY and what might be influencing it. It is clearly possible that an application may be doing something in particular that is triggering a memory leak elsewhere. In this case Apache which is thus most likely related to mod_php which is embedded in Apache and which is what is used to compile and interpret the page execution.
Now one thing that seems to be noted here is that the System Status page, when left up, exposes the apparent memory leak. Why is that? Well System Status page fires off ajax calls at regular intervals, which to the server is no different then if you sat there refreshing the page at those same intervals. So it is basically exercising page loads multiple times per minute thus potentially triggering what ever it may be in apache/mod_php that is creating this memory leak. As far as a bandaid, there is an advanced setting to change the frequency of the ajax refreshes to that page so if you do leave it up it won’t refresh as often which you may want to look at.
If someone wants to try and dig further, I would suggesting starting something really simple. First, create a page script that does almost nothing other than assures the php interpreter is engaged, and provides an ajax call that continuously reloads that page at a very rapid rate. That will tell us if the mere loading of a virtually empty PHP page is related to this. If that does not pan out, then augment that by using our existing libraries to open up a MySQL connection as FreePBX does when these ajax calls are called and go through the same thing to see if a memory leak is exposed. If not, do the same thing but with an Asterisk Manager connection as we do.
The bottom line here is … staying focused on WHERE the actually memory leak could be is going to to a lot further then thinking “The System Status Page” or FreePBX 2.10 has a memory leak. One or both of those could very likely be exercising something in the subsystems that they use that has the actual memory leak which is the point of all this, but staying focused on the fact that the web application can’t have a memory leak, per-se, will help to keep from going in circles.
I’ll close with one comment, the web application could be responsible for a memory leak in one place, which would be if it had a continuous build up of the php SESSION that is reloaded and does have a sense of “memory” across page loads, but that is something that should be pretty trivial to test for by simply adding a dbug() statement to dump the session every page load in the System Status and view if something is growing in there…