[Asterisk-Users] Top and asterisk performance

Julian Lyndon-Smith asterisk at dotr.com
Fri Oct 28 16:33:21 MST 2005


Oh man, stupid of me - I forgot to include that info at the start. 
However, there are a couple of things that come out of the analysis:

1) I've restarted the * server. I now have

top - 00:29:08 up 13 days, 10:50,  1 user,  load average: 0.00, 0.01, 1.04
Tasks:  83 total,   1 running,  82 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.3% us,  0.0% sy,  0.0% ni, 99.7% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:   1034640k total,   270408k used,   764232k free,    42524k buffers
Swap:  2031608k total,        0k used,  2031608k free,   153256k cached

*much* better :)

2) There were about 10 channels that were constantly trying to call: It 
turns out that the agentcallbacklogin has had a change of parameters in 
the past couple of days, one that basically meant that the original 
dialplan caused the system to start eating cpu cycles. So my old dial 
plan seemed to cause the issues. I did realise that there was a problem 
early on, in that agents couldn't login. After a (quick!) bit of 
research, I discovered that the dialplan needed changing, changed it, 
did a "extensions reload" and voila! Agents could log in. I forgot about 
the 10 or so "crashed" (see below) channels.

foxtrot*CLI> show channels
Channel              Location             State   Application(Data)
Local/6041 at AgentQ-a2 6041 at AgentQ:3        Busy    Busy()
Local/6041 at AgentQ-a2 s at AgentQ:1           Down    (None)
Local/6036 at AgentQ-33 6036 at AgentQ:3        Busy    Busy()
Local/6036 at AgentQ-33 s at AgentQ:1           Down    (None)
SIP/711-6416         8888 at from-sip:1      Ring 
AgentCallbackLogin(711|@AgentQ
SIP/711-8145         *8888 at from-sip:1     Ring 
AgentCallbackLogin(8888|711 at Ag
SIP/711-5ff9         8888 at from-sip:1      Ring 
AgentCallbackLogin(711|@AgentQ
SIP/6035-3c31        *6035 at from-sip:1     Up 
AgentCallbackLogin(6035|6035 at A
SIP/6033-a08c        *6033 at from-sip:1     Up 
AgentCallbackLogin(6033|6033 at A
SIP/6025-c55c        *6025 at from-sip:1     Up 
AgentCallbackLogin(6025|6025 at A
SIP/6035-4ef0        *6035 at from-sip:1     Up 
AgentCallbackLogin(6035|6035 at A

At midnight, * automatically restarts, and now top is showing the 
results above. I can only assume that it was the result of those channels.

[root at foxtrot html]# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- --system-- 
----cpu----
  r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us 
sy id wa
  0  0      0 764280  42584 153196    0    0     1    17   29    14  5 
4 91  0
  0  0      0 764280  42584 153196    0    0     0     9 2051   143  0 
0 99  1
  0  0      0 764280  42584 153196    0    0     0    30 2026   124  0 
0 100  0
  0  0      0 764280  42584 153196    0    0     0     0 2022   122  0 
0 100  0
  0  0      0 764280  42588 153192    0    0     0    18 2023   134  0 
0 99  0


I also assume that the following is normal (something about threads ...)

[root at foxtrot html]# ps -ef|fgrep asterisk
root     31462     1  0 00:00 ?        00:00:00 /bin/sh 
/usr/sbin/safe_asterisk
root     31473 31462  0 00:00 ?        00:00:00 /usr/sbin/asterisk -vvvg -c
root     31514 31473  0 00:00 ?        00:00:00 /usr/sbin/asterisk -vvvg -c
root     31516 31514  0 00:00 ?        00:00:00 /usr/sbin/asterisk -vvvg -c
root     31517 31514  0 00:00 ?        00:00:00 /usr/sbin/asterisk -vvvg -c
root     31518 31514  0 00:00 ?        00:00:00 /usr/sbin/asterisk -vvvg -c
root     31519 31514  0 00:00 ?        00:00:00 /usr/sbin/asterisk -vvvg -c
root     31520 31514  0 00:00 ?        00:00:00 /usr/sbin/asterisk -vvvg -c
root     31521 31514  0 00:00 ?        00:00:00 /usr/sbin/asterisk -vvvg -c
root     31522 31514  0 00:00 ?        00:00:00 /usr/sbin/asterisk -vvvg -c
root     31523 31514  0 00:00 ?        00:00:00 /usr/sbin/asterisk -vvvg -c
root     31524 31514  0 00:00 ?        00:00:00 /usr/sbin/asterisk -vvvg -c
root     31525 31514  0 00:00 ?        00:00:00 /usr/sbin/asterisk -vvvg -c
root     31526 31514  0 00:00 ?        00:00:00 /usr/sbin/asterisk -vvvg -c
root     31527 31514  0 00:00 ?        00:00:00 /usr/sbin/asterisk -vvvg -c
root     31528 31514  0 00:00 ?        00:00:01 /usr/sbin/asterisk -vvvg -c
root     31529 31514  0 00:00 ?        00:00:00 /usr/sbin/asterisk -vvvg -c
root     31530 31514  0 00:00 ?        00:00:00 /usr/sbin/asterisk -vvvg -c
root     31531 31514  0 00:00 ?        00:00:00 /usr/sbin/asterisk -vvvg -c
root     31532 31514  0 00:00 ?        00:00:00 /usr/sbin/asterisk -vvvg -c
root     31646 30821  0 00:34 pts/0    00:00:00 fgrep asterisk

Many thanks for all the help.

Julian.

Steve Kann wrote:
> Julian Lyndon-Smith wrote:
> 
>> We had to move from a old * server to a new one in a hurry (hardware 
>> failure). The old server was a dual pentium 700 with 512MB ram running 
>> fedora core 2, the new one is a single 3GHz Pentium with 1gb ram.
>>
>> The same number of people are connected to the new server as the old, 
>> the same number of inbound calls to the isdn30 etc (on average 20 
>> calls active at any time (SIP and ZAP)). Basically, just a server 
>> swapout.
>>
>> I must be reading top wrong, because the old server had a idle of 
>> approx 30%, whereas the new server is
>>
>> top - 13:35:21 up 12 days, 23:57,  1 user,  load average: 7.11, 7.20, 
>> 7.21
>> Tasks:  98 total,   9 running,  89 sleeping,   0 stopped,   0 zombie
>> Cpu(s): 99.0% us,  1.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  
>> 0.0% si
>> Mem:   1034640k total,   144792k used,   889848k free,    21952k buffers
>> Swap:  2031608k total,        0k used,  2031608k free,    61248k cached
>>
>> Notice the 99.0% us. This fluctuates between 80 and 99%.
>>
>> The other difference is that the new server is on cvs-head as of today 
>> - I did say that it was an emergency :) whereas the old server was 
>> cvs-head from june sometime.
>>
>> Is it just me, or is there a problem ?
> 
> 
> 
> Well, I suppose it depends on what's using all that CPU -- you leave 
> that part out.
> 
> Assuming it's asterisk threads causing the 100% cpu usage, and the load 
> average of 7, then, yes, that's a lot of CPU.
> 
> But, you could have some other program/processes doing that, and if 
> they're batch processes (they're clearly not niced), they may end up 
> with a lower dynamic priority and not affect asterisk too much.
> 
> -SteveK
> 
>>
>> Julian.
>> _______________________________________________
>> --Bandwidth and Colocation sponsored by Easynews.com --
>>
>> Asterisk-Users mailing list
>> Asterisk-Users at lists.digium.com
>> http://lists.digium.com/mailman/listinfo/asterisk-users
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>
> 
> _______________________________________________
> --Bandwidth and Colocation sponsored by Easynews.com --
> 
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
> 
> 




More information about the asterisk-users mailing list