[Home]

Summary:ASTERISK-24793: Asterisk spirals to high load when audio stream fed to MOH disappears
Reporter:univ (univ)Labels:
Date Opened:2015-02-14 17:31:18.000-0600Date Closed:2015-04-29 08:16:08
Priority:MinorRegression?
Status:Closed/CompleteComponents:Resources/res_musiconhold
Versions:11.4.0 11.16.0 Frequency of
Occurrence		Constant
Related
Issues:
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.Attachments:( 0) issue_24793_log.txt
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.
Comments:By: Rusty Newton (rnewton) 2015-02-20 17:11:21.224-0600

We require additional debug to continue with triage of your issue. Please follow the instructions on the wiki [1] for how to collect debugging information from Asterisk. For expediency, where possible, attach the debug with a '.txt' file extension so that the debug will be usable for further analysis.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information


By: Rusty Newton (rnewton) 2015-03-11 17:29:22.974-0500

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines


By: Joshua C. Colp (jcolp) 2015-03-12 08:21:51.995-0500

<Stefan95> Hello!
<Stefan95> A bug I filed got closed because I was too slow with providing the requested debug information. Now I've collected that info and would like to ask a bug marshall to reopen the bug: ASTERISK-24793
By: univ (univ) 2015-03-12 08:29:07.072-0500

Logfile of described effect. At that time one out of 6 audio streams was down (or had some network issues). Resulted in this: load average: 77.73, 70.11, 66.51. About 215 active calls to MOH at this moment.
By: univ (univ) 2015-03-12 08:30:21.579-0500

Sorry for the delay. Log attached.
By: Rusty Newton (rnewton) 2015-04-13 19:12:45.166-0500

Are you able to reproduce this same issue if you only have a few active streams, lets say 3 or 4, and one of them goes down? Does the CPU usage still jump up?

Essentially, please attach a small scale reproduction guide with clear steps to reproduce the issue.
By: Rusty Newton (rnewton) 2015-04-29 08:15:38.345-0500

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines