Aastra Scripts and Processor Load

Discussion in 'General' started by blangys, Dec 16, 2010.

  1. blangys

    Joined:
    Sep 24, 2009
    Messages:
    94
    Likes Received:
    0
    Howdy - I'm chasing a voice quality issue at a customer. I think it is due to the Aastra scrips spiking the processor for state updates, but I don't know. I have generally OK voice quality but I get some dropped audio and clicking when I do a call park and it seems on a multicast page as well.

    Processor spikes to 80 - 90 percent when parking calls. Audio is disrupted when that is going on.

    Video attached [video]http://www.youtube.com/watch?v=qwtxpfh3InU[/video]for your review:

    Help me Obi Wan, You're my only hope! (Obi Wan = Elastix Community)

    Bob Langys
    www.langys.com
     
  2. Lee Sharp

    Joined:
    Sep 28, 2010
    Messages:
    332
    Likes Received:
    0
    I have about 45 Aastra phones and another 35 soft phones on my server, and I can not replicate your problem. I am on 2.0.x in my office.
     
  3. blangys

    Joined:
    Sep 24, 2009
    Messages:
    94
    Likes Received:
    0
    Lee - do you have the XML Scripts installed? Do you have a default set of buttons, or did you remove some of them? Thanks!
     
  4. Lee Sharp

    Joined:
    Sep 28, 2010
    Messages:
    332
    Likes Received:
    0
    Totally default with nothing special. What, exactly, did you modify and how?
     
  5. blangys

    Joined:
    Sep 24, 2009
    Messages:
    94
    Likes Received:
    0
    The only thing we changed was the demouser.prf to remove some of the buttons. Customer doesn't use presence so we took it out, and we reordered some of the buttons as well.
     
  6. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    Perhaps you will find after the recommended (and, I suggest, obligatory) "RTFM'ing" ref:

    http://www.aastratelecom.com/cps/rde/xb ... -05-00.pdf

    (you will notice that aastra claims only 32 bit kernel compliance, caveat implimentor)

    that the recommended way of deploying the various aastra templates and modifying the xml server behavior is by editing the files in

    /var/www/html/aastra/config

    for example copy the original and pristine demo-user.prf template file to blangys-user.prf

    cp -p /var/www/html/aastra/asterisk/demo-user.prf /var/www/html/aastra/asterisk/blangys-user.prf

    (and again for other purposes perhaps leesharp-user.prf) , then edit THESE instances to suit. Then in

    asterisk.conf

    edit to something like

    [Profiles]
    blanygs=8217,8238,9524-9542
    leesharp=8212,8718
    .
    .
    .

    (Then when you FUp you can do it over with less wasted time)

    and change, if, as in your case, you don't want to use the presence app,


    [Presence]
    # Presence application enabled (1) or not (0), default is 1
    enabled=0

    because if the server finds the "disabled (i.e. "we took it out' ) " clients to be non receptive, it will simply "just take longer" to not deliver it's messages (think about it ;) ) .

    perhaps further modification of parking etc. the other files in that directory are all useful for customizations also.

    I find this method effective in serving many dozens if not hundreds of aastra phones in a multi-tenant deployment or even in a call-center with far less pain or server load. (Call Centers being a little more problematic due to the current (1.4/1.6) way of handling queues/hints)

    p,s, as an off the wall comment would not demouser (sic) in linux be cat?
     
  7. blangys

    Joined:
    Sep 24, 2009
    Messages:
    94
    Likes Received:
    0
    Dicko,

    Took the actions you suggested, but I still have a high processor load. We had a failure and had restored to the same piece of equipment. (it was a motherboard failure) It's possible that we have some corruption somewhere.

    Anyway - Any chance you can connect to the system to have a look around? Let me know how to reach you and what your rate would be. We have a VPN connection (Cisco) that I can get you access to.

    Bob Langys
    Email address is bob (at) langys.com

    Thanks!
     
  8. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    I'm sorry Bob, I won't do that, I consider these fora to be non commercial. I do not publish my personal contact info also for past reasons :)

    however, if I thought for a moment that there might be corruption in a system, I would certainly return to an image I took earlier, and restore the data as necessary, other wise there is just one too many unknowns, If the problem remains then I would start by profiling the two php aastra daemons /var/www/html/aastra/asterisk/aastra_daemon1 and /var/www/html/aastra/asterisk/aastra_daemon2, although as I say, I have never seen such behavior.


    good luck

    dicko
     
  9. blangys

    Joined:
    Sep 24, 2009
    Messages:
    94
    Likes Received:
    0
    Ok, Dicko. Any idea where I can turn to on this? The more I think about it the more it points to overall processing power on my system. I've got a Xorcom 2047 as the server and it supports the calls just fine. I've reloaded the system and tried again, and when we park calls the HTTPD service goes wild and the processor spikes to 80 percent or so. In our test environment I cannot really get the processor to spike fully, but at the customer site I know they are parking a number of calls with activity on the line.

    How about hosting the XML on another box? Any ideas on that? My alternative is to bring them down again to reload on a larger platform. That's not good for anyone!

    Thanks for your help thus far. I don't know what you meant by "profiling" the php daemons other than to take a look. I'm not really familiar with PHP except for knowing that it generates the activity on the fly and is by nature more processor intensive than static html or xml pages.

    Thanks!

    Bob.
     
  10. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    Well, I just don't see such problems, but all my larger production servers remain in the reliable domain of Asterisk 1.4 (commonly Elastix 1.6, but by no means all of them) and 32 bit kernels.

    If however I noticed such behavior I would start with

    ps ax|grep aastra

    which would give me the pid's of aastra_daemon1 and 2

    then

    lsof +c 15 -i :5038

    to get the ports that the daemons are using to connect to AMI

    Then watch simultaneously

    tcpdump tcp port 5038 -i lo

    which will display the traffic on AMI ( you can of course use the lsof values to restrict to either daemon of course)

    tcpdump tcp port 80 (for the raw http traffic, which in a standard Elastix+aastra install will ONLY be the Aastra traffic)

    and

    tail -f /var/log/httpd/access_log

    this might well show what is getting hung up and where, i.e. a sent package waiting on a dependent service etc.)


    I find after a while of watching such streams, the sub-conscience can often identify incongruence quite quickly.

    debugging is usually best thought of as more art than science, i doubt that is a cpu power problem, more a stalled process or ninety

    good luck

    dicko
     
  11. blangys

    Joined:
    Sep 24, 2009
    Messages:
    94
    Likes Received:
    0
    In the end the answer for us was a larger processor. The processor / memory combo that we had in place in both locations was fine for the call load, but not for the additional load imposed by the Apache / XML / Aastra 9480i interaction. The systems never went down hard but it was enough to make calls sound bad. Chalk up another learning experience!
     
  12. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    I'm glad it worked for you Bob,

    There are many tools in our tool chest, as I said the load should be trivial, If you used a sledge hammer instead of forceps, then you are off the hook for now, do you still see the same overloaded and horribly latent apache connections?

    regards

    dicko
     
  13. blangys

    Joined:
    Sep 24, 2009
    Messages:
    94
    Likes Received:
    0
    Dicko - I still see activity, but with a faster processor it's of no impact. I've got three other sites with the same platform and Aastra phones and they are not having any issues but they are not really parking calls that much. These last two sites were heavy on the pickup call - park call - page cycle.

    Thanks for your help!
     

Share This Page