[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