[Asterisk-Dev] spike / asterisk hang? <- On a 360MHz CPU

Jim Van Meggelen jim at vanmeggelen.ca
Fri Jul 15 10:38:54 MST 2005


asterisk-dev-bounces at lists.digium.com wrote:
> We have a steadily growing dial plan for our users on a sparc
> netra t105.. I have noticed that audio going through the
> asterisk (stable) system
> sometimes becomes choppy (cuts out and restores after a few
> seconds) when new calls are being handled.. on the system
> running a vmstat 1 I watch the traps sys counter jumps up
> really high from the 
> normal run stats..

I would say that is to be expected on such a platform. Running Asterisk
on a system with a 360MHz CPU is going to limit the number of concurrent
calls you can handle.

Although at first glance this may seem a dev issue, it is not. It is a
performance issue -- Asterisk performs all DSP work in the CPU, so as
the load on the system increases, the chance that callers will hear the
degradation increase. This should probably be submitted to the user's
list for any further discussion (or taken off line).

> An example dialplan entry for a user is as simple as:
> exten => 201,1,Dial(SIP/201,,t)
> (we've got a few hundred of these but note that we only have
> around 15
> calls active at any given time)
> because of the transfer requirement media goes through the
> asterisk server.. we are using sip on both side of the
> asterisk server ulaw codec is
> preferred at the endpoints.
> 
> Here's a vmstat at 1 second intervals .. at the time there
> are 8 active
> calls:
>  procs   memory        page                    disks
> traps         cpu
>  r b w      avm         fre   flt  re  pi  po  fr  sr sd0 cd0 
>  int sys   cs us sy id 0 0 0  42288 868840     7   0   0   0  
> 0   0   0   0  367 469   61 0  0 100
>  0 0 0  42288 868840     7   0   0   0   0   0   0   0  395
> 802   92 1  0 99
>  0 0 0  42288 868840    12   0   0   0   0   0   0   0  377
> 554   64 0  0 100
>  0 0 0  42288 868840     7   0   0   0   0   0   0   0  359
> 476   62 0  0 100
>  0 0 0  42288 868840     7   0   0   0   0   0   0   0  364
> 468   62 0  0 100
>  0 0 0  42288 868840     7   0   0   0   0   0   0   0  375
> 459   61 0  0 100
>  0 0 0  42288 868840     7   0   0   0   0   0   0   0  364
> 480   61 0  0 100
> 
> But on processing a call vmstat's sys traps and cpu cs
> counters both jump way up.. 
> 
>  procs   memory        page                    disks
> traps         cpu
>  r b w      avm         fre   flt  re  pi  po  fr  sr sd0 cd0 
>  int sys   cs us sy id 0 0 0  42280 868848     7   0   0   0  
> 0   0   0   0  709 1429  160 3  1 96
>  0 0 0  42288 868840    11   0   0   0   0   0   0   0  659
> 1395  168 0  0 100
> 
> This issue has steadily gotten worse with the addition of
> more dialplan
> entries like the one above..

That is to be expected.

> Note that as long as all calls are active and setup (nothing
> happening involving dialplan) audio is perfect.. only when
> dialplan processing happens does asterisk seem to hang up for
> a second.. 

That's because the introduction of a new call to the system requires
work on the part of the CPU. Once the channel is established there's
very little for the CPU to do.

> Am I going crazy or am I near the mark in troubleshooting
> this.. and if
> so (near the mark and not crazy) then how can I help improve
> the situation?

Perhaps there are some performance optimizations that could improve
matters somewhat, but I suspect that the least expensive, most painless
way to resolve it is to replace the system with something more powerful.

Oh, also, you are ONLY running Asterisk on that server, yes? No
database, web server, GUI desktop, or such?

Regards,

Jim.


--
Jim Van Meggelen
jim at vanmeggelen.ca
www.oreillynet.com/cs/catalog/view/au/2177

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.8.15/49 - Release Date:
14/07/2005
 




More information about the asterisk-dev mailing list