Asterisk High Load When Streaming MOH

Home » Asterisk Users » Asterisk High Load When Streaming MOH
Asterisk Users 5 Comments

Hi list,

I’ve always about 50 concurrent SIP callers listening to several MOH
streams (fed via mpg123) on Asterisk 11.4.0, 4x 2.2 GHz and the CPU
usage is always at about 250% causing stuttering of the streams and delays when using Read() and Playback() (overall everything is just really slow/delayed). I’ve seen Asterisk doing that when the MOH stream that was fed via mpg123 was down… then it will just go nuts. But I’m pretty sure that all streams are active (checked via strace). My question is what would be the best way to look at the internals of Asterisk to really find out what exactly is causing that high CPU load?

Thank you!
Markus

5 thoughts on - Asterisk High Load When Streaming MOH

  • Sometimes I see something similar on my systems when several (3 or more) MOH streams are fed by mpg123. Suddenly some or all streams are stuttering, but the CPU load doesn’t seem to go up significantly.

    Have you looked at what is happening with the receive queue of mpg123 (pgrep mpg123 and netstat
    -t -p)?

    I have written a small daemon for myself that watches the receiving tcp streams and if nothing seems to be happening, simply touches musiconhold.conf and issues an “asterisk -rx \”moh reload\””. Not nice, but it works, eventually. When I listen to the same music streams I find that they are not as stable as one would wish, at least at a time scale of several hours.

    When using several moh file classes, I have never hat audio problems.

    jg

  • Am 20.09.2013 15:17, schrieb jg:

    My CPU load is permanent at 200-250%. I have 7 active mpg123 streams.

    On another box running Asterisk 10.8.0, 4x 2.4 GHz, I have 49 active streams, but they get fed via mplayer instead of mpg123. There the load is close to zero, but I have to say that I have only 1-2 concurrent callers there. Strange!

    netstat -t -p shows me each of the 7 IP addresses and Recv-Q has some bytes listed (55000 – 113000) for each IP. According to man netstat Recv-Q means “The count of bytes not copied by the user program connected to this socket”. Note the “not”. Now, is that good or bad?

    What I do is simply call killall mpg123 every 10 minutes via cron. Asterisk MOH will restart the process immediately and there will be less than a second of silence for the listener. Not that elegant but it helps with hanging audio streams…

    Me neither.

    Thanks!
    Markus

  • My understanding is that the mpg123 stream gets decoded only a single time regardless of the number of listeners. I see about the same values. The values should be varying and as low as possible. So 0 for a couple of minutes could mean that the stream is dead. My solution is essentially the same, only the other way around and based on whether a stream seems to be dead. “moh reload” essentially kills any mpg123 instances and restarts them. I was just too lazy to study the Asterisk sources carefully. When skimming the code there were quite a few “Uh Oh. …” comments, and I assumed that “moh reload” is probably a safer thing to do than just killing mgp123.

    My system issues an “moh reload” maybe once or twice a day, and sometimes not even a single time. When I use Shoutcast streams there a a lot more restarts a day.

    jg

  • Am 20.09.2013 16:37, schrieb jg:

    I thought so. So, I need to dig deeper… but how?

    Some command to show the different Asterisk internal sub-processes stats would be nice to begin with. Like what exactly is consuming that much CPU.