[asterisk-users] Monitor application inestability and high load

[Matthew J. Roth]

Edgar A. Luna Diaz wrote:
>
> I'm having high load, choppy sound and slow responsives with an 
> asterisk server (version 1.2.12.1) that make a peak of 90 channels 
> (around 60 phones calling at max, isn't necessary to reach this peak 
> to get the problem). All the traffic is SIP, with recording for every 
> call.
>
What codecs are you using?  Are you performing any transcoding?  What 
format are you using for the recordings?
>
> The problems are detected in the high count of asterisk processes and 
> sh wrappers to soxmix which could be as old as 1 hour in the server 
> without a reason to stay idle, but for some unknow reason this "sh" 
> don't die fast. This is when the dialplan calls Monitor obviously. I 
> already tried to switch to MixMonitor but yesterday users reported 
> that in some calls the recording isn't complete. Which is similar to a 
> bug that is mentioned in mantis but for versions prior to 1.2.7. The 
> asterisk logs don't show any particular message in verbose level 3. 
> Apart from the recording, I have a high use of Manager and the mysql 
> is used for some bussines logic but I think that nothing to high load, 
> indeed mysql never is the most important part in processor, memmory 
> and disk access statistics.
>
What do your disk access statistics look like?  In my experience, your 
call quality will begin to seriously deteriorate as you approach 60 
simultaneous recordings.  This is because the Monitor() code places a 
disk write in the code path that bridges channels.  If it's possible to 
disable recordings for a while, you can confirm whether or not this is 
the source of your problem.
>
> Any knows a solution to this problem? or has an explanation for it?
>
In general, you should try to offload as many processes from the 
Asterisk server as possible.  MySQL is a good candidate for that, but 
the big one is soxmix.  Transcoding audio files is CPU intensive and I 
wouldn't be surprised if it impacted your call quality.

I've overcome the Monitor() problem by writing to a RAM disk.  At the 
end of each call, the recordings are moved from the RAM disk to a remote 
machine via NFS where they are mixed and indexed for retrieval.  My 
documentation of this process is available here:

<http://thread.gmane.org/gmane.comp.telephony.pbx.asterisk.user/118497>

and here:

<http://lists.digium.com/pipermail/asterisk-users/2005-October/120930.html>

Note that we are overconfigured for RAM.  You could probably get away 
with a 2 GB RAM disk.  I've also made some refinements to the setup that 
increased reliability.  If you choose to go down this path, I'll be 
happy to discuss them with you.

Matthew Roth
InterMedia Marketing Solutions
Software Engineer and Systems Developer