[Asterisk-Dev] spike / asterisk hang? <- On a 360MHz CPU - no, 440 :)

alex at pilosoft.com alex at pilosoft.com
Fri Jul 15 12:15:18 MST 2005


On Fri, 15 Jul 2005, Matt Hess wrote:

> See that's the thing.. the idle indicator on vmstat never shows the cpu
> bottom out.. 96 % idle should not be the culprit for the reason why
> asterisk hangs the audio.. at least in my mind it should not be..  I
> could understand a high influx of interrupts having an impact like this
> but system calls and traps? That sure feels/seems less likely to me to
> be able to literally stop the flow of packets from the system when a
> call comes in or out.. and I've tested this out extensively.. it is only
> asterisk packets that stop.. other processes on the system perform as
> they should.. heck, a ping to a router keeps sending packets when
> asterisk stops sending it's audio..
You are not listening. When the CPU is busy, no audio will be forwarded. 
Pings are processed in kernel, without context switch, this is a very bad 
comparison. Asterisk voice frame forwarding happens in the asterisk 
process.

> I strongly believe that there is something more sinister lurking beneath
> this problem than simply cpu restrictions.
How about you try running asterisk on a 2005 hardware.

> But heck.. I suppose I can just ask this question.. why the heck does
> asterisk generate so many traps and system calls when processing a call?
Because it has to.

> When completely idle my asterisk system sees about an average of 70 sys 
> traps a second.. when a call comes in.. the sys traps alone increase 
> over a 1000% increase.. and that is to a simple dialplan of just:
> exten => 401,1,Dial(SIP/401)
> 
> So I guess my question has morphed into something along the lines of:
> Why is the dialplan so expensive to parse and has or is any work going
> into making it more system friendly or efficient?
No, it is time to get with the times. Get decent hardware.

-alex




More information about the asterisk-dev mailing list