One more comment to all this … if you think there are memory problems, then DON’T use the System Status memory information to make a conclusive judgment. Although we try to put reasonable information there, there are some systems and some times where that can be inaccurate and in either way it provides very little granular detail.
So … in diagnostic situations, use Linus system tools to monitor what is going on more closely, such as top, free, ps, etc.
I have found htop a great tool for monitoring memory and CPU usage
cd /usr/src
wget http://pkgs.repoforge.org/htop/htop-1.0.1-1.el5.rf.i386.rpm
rpm -ivh htop (hit the tab key to complete the filename)
now just type htop
If you are messing with the beta 64 bit distro use:
http://pkgs.repoforge.org/htop/htop-1.0.1-1.el5.rf.x86_64.rpm
Hey SkykingOH,
Great post, nice tool. Post this over in the tips section.
Are you sure your problem is not just cached memory filling up? That is normal if it is. You should subtract cached memory from total memory to get actual memory used.
I still don’t understand why you guys continue reporting memory usage this way in the dashboard when it constantly causes this confusion. It’s useless to include cached memory imho because of the way it works. All you need to do is subtract cached memory on line 206 of /admin/modules/dashboard/page.index.php.
So change:
$app_memory = isset($memory[“ram”][“app”]) ? $memory[“ram”][“app”] : $memory[“ram”][“total”] - $memory[“ram”][“t_free”] ;
to
$app_memory = isset($memory[“ram”][“app”]) ? $memory[“ram”][“app”] : $memory[“ram”][“total”] - $memory[“ram”][“t_free”] - $memory[“ram”][“cached”];
This is what I do manually on my servers. Simple fix. A much more useful indicator imho. Much less confusion of what is being reported imho.
I wish you guys would do this permanently on your end so I don’t have to change this manually on my end every time freepbx framework is updated.
I would suggest you open a feature request on this. On the right you will see Report Bug/Feature.
I’ve read through the whole thread and can’t find if this was resolved or not? I want to upgrade my 2.9 box to 2.11 and setup a backup server run it.
The system was created using the 1.87.29 distro and upgraded via scripts. After about a day of being on (no phones or trunks connected yet) my app mem is running about 85% (testing server only has 1gb ram).
My system did have FOP2 installed and google voice, but I removed them for testing with no change. One thing I did notice is FOP1 keeps trying to load even after I uninstalled the module.
[code]STARTING FOP SERVER
Missing security_code in op_server.cfg! at /var/www/html/admin/modules/fw_fop/op_server.pl line 592.
[/code]
I am experiencing a similar issue with the latest version, running the following specs:
Intel Celeron DC E3400 2.60GHz Dual-Core 775 RET Processor
Super Micro X7SLM-L-B 775 V 2D2 M2 2GL R B Motherboard
2GB DDR2-800 PC2-6400 Memory
500GB SATA3 7200RPM 16MB Cache
503B Rev. L 1U 1 Bays 200W PSU Chassis
any resolution yet?
What is the temporary fix? Crontab an httpd restart at intervals? What is a good interval?
There is no fix as nobody can consistently reproduce this or tell us how to reproduce it.
Tony,
I’m fairly certain that it’s not a hardware issue. I have reproduced it 4 times (on the same test machine) by upgrading 2.9 by the web module then continued to update via scripts. My 2.9 box had google voice, fop2, and custom context modules added. I also had webmin installed. I’ve tried uninstalling them then upgrading with no difference. However, when I did a clean 2.11 distro install and add those modules and webmin, no memory leak at all. Hopefully this helps troubleshoot.
Topic seems to have gone quite… I am experiencing this on my own dedicated server. I never noticed it until this week when calls was going direct to voicemail.
I do not constantly keep open the status screens, in fact it runs on its own in the corner with no interference from me or anyone else. When I did notice I was not getting calls, I looked at my status screen to see my app memory almost peaking out! A quick restart of the httpd fixed this until the next day.
I recently did run chown -R asterisk:asterisk /var/lib/php/session and tried to yum install php *, I have the most recent version so this did no good for me. Again I ran the service httpd restart and my app memory is holding at 24 - 25 % which is higher then normal. It used to sit at around 16% or so.
Will continue to monitor the results of the memory and post back here, I for one do not think it has anything to do with the monitor screen. As mentioned, I am hardly in it.
Been a few days, and now my App memory has dropped below 21%. I followed some information in this thread and what ever it was, fixed it.
Thanks…
hello,
I know this thread has been active just thought I would put in my findings as well. I came in this morning and looked at my asterisk servers I have 3 of them. All 3 were at 93% App Memory .... I didn't know what to do so I read this and restarted apache on all 3 the mem went from 93% down to 13% however I just looked at my main server and jumped back up to 24%.
Right after my restart of apache it drops then jumps back up.
This could be a problem for me because we have 2 servers in Mumabi India and they are 11 and 1/2 Hours ahead of us.
Has this been resolved ? I just installed 2.10.1.5 and as of right now the server does not have any extensions or activity and I am sitting at 90%. Whats the issue here ?
I have several instances on virtual machines and most of them have this issue, httpd restart in different time periods helps, but in one instance Im restarting it every minute and even with it system can shutdown machine. Disabling httpd helps. Im using 2.10.1 version.
I’ve dealt with this memory leak for quite some time through httpd restart cron jobs. While I cannot identify the exact source of it, I absolutely know it’s related to the CentOS foundation of the FreePBX distro. I just manually built a FreePBX server on Ubuntu (using the simple steps when you google “FreePBX on Ubuntu 12.04” and I’m supporting 110 IP Phones with no memory leak issues at all. The memory leak was quite severe for us because we used an HTTP provisioning mechanism w/5 minute provisioning check-ins; our cron job was running once every 5 minutes (ugh).
Hope this helps!