[asterisk-bugs] [JIRA] (ASTERISK-24793) Asterisk spirals to high load when audio stream fed to MOH disappears

[univ (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-24793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

univ updated ASTERISK-24793:
----------------------------

    Description: 
I was unsure whether this should be classified as a bug or improvement. But since, when it happens, it has an impact on the remaining Asterisk functionality, I chose bug.

I'm feeding several MP3 streams to Asterisk' MusicOnHold like this:

musiconhold.conf:

[stream1]
mode=custom
application=/var/lib/asterisk/mohstream-stream1.sh

mohstream-stream1.sh:

#!/bin/bash
/usr/bin/mpg123 -q -r 8000 --mono -s http://stream.url

Everything's fine by default. 250+ MOH streams in parallel on a single Quad Core VM, no problem. Load 0.xx to 1.xx. But as soon as any of the http://stream.url goes down for whatever reason, load will rise to 70, 150 and more. top shows that the asterisk process starts to consume hundreds of % of CPU. Input on the console starts to lag and so does all audio that Asterisk serves to callers. Fix the stream.url and everything's fine again.

I've checked that the cause is the stream.url that's gone by looking at the mpg123 process with strace, which, by the way, re-spawns constantly and I guess that's part of the problem.

  was:
I was unsure whether this should be classified as a bug or improvement. But since, when it happens, it has an impact of the remaining Asterisk functionality, I chose bug.

I'm feeding several MP3 streams to Asterisk' MusicOnHold like this:

musiconhold.conf:

[stream1]
mode=custom
application=/var/lib/asterisk/mohstream-stream1.sh

mohstream-stream1.sh:

#!/bin/bash
/usr/bin/mpg123 -q -r 8000 --mono -s http://stream.url

Everything's fine by default. 250+ MOH streams in parallel on a single Quad Core VM, no problem. Load 0.xx to 1.xx. But as soon as any of the http://stream.url goes down for whatever reason, load will rise to 70, 150 and more. top shows that the asterisk process starts to consume hundreds of % of CPU. Input on the console starts to lag and so does all audio that Asterisk serves to callers. Fix the stream.url and everything's fine again.

I've checked that the cause is the stream.url that's gone by looking at the mpg123 process with strace, which, by the way, re-spawns constantly and I guess that's part of the problem.


> Asterisk spirals to high load when audio stream fed to MOH disappears
> ---------------------------------------------------------------------
>
>                 Key: ASTERISK-24793
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24793
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_musiconhold
>    Affects Versions: 11.4.0, 11.16.0
>         Environment: Linux CentOS 6.6 (latest) 64bit 2.6.32-504.8.1.el6.x86_64 and Linux CentOS 6.4 64bit 2.6.32-358.6.2.el6.x86_64.
>            Reporter: univ
>            Severity: Minor
>
> I was unsure whether this should be classified as a bug or improvement. But since, when it happens, it has an impact on the remaining Asterisk functionality, I chose bug.
> I'm feeding several MP3 streams to Asterisk' MusicOnHold like this:
> musiconhold.conf:
> [stream1]
> mode=custom
> application=/var/lib/asterisk/mohstream-stream1.sh
> mohstream-stream1.sh:
> #!/bin/bash
> /usr/bin/mpg123 -q -r 8000 --mono -s http://stream.url
> Everything's fine by default. 250+ MOH streams in parallel on a single Quad Core VM, no problem. Load 0.xx to 1.xx. But as soon as any of the http://stream.url goes down for whatever reason, load will rise to 70, 150 and more. top shows that the asterisk process starts to consume hundreds of % of CPU. Input on the console starts to lag and so does all audio that Asterisk serves to callers. Fix the stream.url and everything's fine again.
> I've checked that the cause is the stream.url that's gone by looking at the mpg123 process with strace, which, by the way, re-spawns constantly and I guess that's part of the problem.



--
This message was sent by Atlassian JIRA
(v6.2#6252)