TIPS Incoming calls go to voicemail and "res_agi.c: Failed to fork(): Cannot allocate memory" error

[imekul]

I have a problem where approximately every week or two, all incoming calls will no longer ring ring groups but instead go directly to voicemail.

I had this issue a couple years ago (https://pbxinaflash.com/community/t...olved-by-rebooting-freepbx.17066/#post-110151) but it seemed to ultimately be caused by an incorrect Gmail password inside of /etc/asterisk/jabber.conf.

This time around, it's a new system (Incredible PBX 12.0.74) and I'm not using Jabber.

Looking through /var/log/asterisk/full, when a called is placed and goes straight to voicemail, I see this line:

[2017-02-20 11:43:50] WARNING[13032][C-000006aa] res_agi.c: Failed to fork(): Cannot allocate memory

Again, rebooting the system fixes the problem... for a week or two.

Could this be caused by the system running out of memory? My current system is a virtual server with only 768 MB RAM, so I'm wondering if that could be the culprit.

If memory is likely the issue, I could obviously upgrade my virtual server. OR... is there anything easy that could be done to optimize memory usage inside of FreePBX? I understand 768 MB is fairly low already, but I didn't know if there were potential things I could disable that would free up a significant amount.

Any thoughts on whether memory is indeed the issue and if there's anything that can be done to free up memory?

Thanks!

 

[dicko]

Install sysstat and use sar to watch what was happening before a crasj, logwatch can also be used tp notify on many events/

 

[billsimon]

I have run recent versions of FreePBX on low-memory virtual machines (512MB). Use top to figure out what's using your memory.

You want to maximize the memory available to Asterisk and minimize everything else. I reduced the number of worker processes in Apache down to two. You don't need ten worker processes eating up memory if you're only using the web server for occasional configuration of your system. You may be able to optimize mysql as well. Other than for configuration tasks, mysql is only used for recording call detail records.

If your server doesn't have a swap partition or file, add one. At least you will have a buffer so that the system won't crash when it runs out of memory, but using swap for any amount of time will slow your system to a crawl.

Determine whether any other daemons are running that are not useful. They may only take up a small amount of memory each, but if you disable several, you will gain a fair amount.

 

[imekul]

Thank you for the great advice, billsimon! Would you be able to give me some direction on how to figure out whether any needless daemons are running?

Here are what might be a couple of handy screenshots: http://imgur.com/a/lndx2

The first one shows the memory usage when I had the problem and when I restarted. There's still a decent amount of cached memory shown there in the light green, so would that maybe point to low memory not being the culprit?

The second image is the output of top currently, so when everything is in a working state.

 

[billsimon]

Nothing stands out there, but you might want to sort the top output by the memory column so that you can see what is consuming the most. Since you said it takes a week or two, it sounds like a memory leak, so you will have to monitor occasionally and find out what keeps increasing in memory usage.

 

[dicko]

sar/sysstat , wont won't directly reveal the culprit, it will however expose the fact that it is a problem .

then you can be more more directed as to what's chewing up your memory many ways to slice that apple ;-) weird things than can bite are uncontrolled udev processes, but usually just badly written Java stuff