Has anyone noticed a problem with runaway mpg123 processes for music-on-hold eating up ~100% CPU and driving the load on the machine way up? I've seen this problem consistently with multiple Asterisk installs, 1.2.x and 1.4.x, although admittedly it was more common with 1.2.x as far as I can tell. There is no clearly identifiable sequence of events that causes this to occur, although it obviously involves utilisation of the MOH audio blend at some point, which I use both in queues and for hold. But the precise chain of events is never consistent, predictable, nor triggered in any particular temporal relation to when MOH is last used--at least, not one that I can pin down. It does not appear to arise immediately following the activation of a MOH sequence. -- Alex Balashov <sasha@presidium.org>
Alex Balashov wrote:> Has anyone noticed a problem with runaway mpg123 processes for > music-on-hold eating up ~100% CPU and driving the load on the > machine way up?Alex, I recommend dropping mpg123 for native music-on-hold. There are multiple benefits to this, including avoiding all of the problems related to mpg123. Searching this list for mpg123 will yield a lot of useful results. Here's one, along with a link to AstRecipes documenting music-on-hold without mpg123. music on hold without mpg123 <http://lists.digium.com/pipermail/asterisk-users/2006-March/143476.html> Music-on-hold without MPG123 <http://astrecipes.net/?n=152> Matthew Roth InterMedia Marketing Solutions Software Engineer and Systems Developer
----- Original Message ----- From: "Alex Balashov" <abalashov@evaristesys.com> To: <asterisk-users@lists.digium.com> Sent: Wednesday, May 02, 2007 2:35 AM Subject: [asterisk-users] Runaway MOH/mp3123 process?> > Has anyone noticed a problem with runaway mpg123 processes for > music-on-hold eating up ~100% CPU and driving the load on the > machine way up? > > I've seen this problem consistently with multiple Asterisk > installs, 1.2.x and 1.4.x, although admittedly it was more > common with 1.2.x as far as I can tell. > > There is no clearly identifiable sequence of events that causes > this to occur, although it obviously involves utilisation of the > MOH audio blend at some point, which I use both in queues and for > hold. But the precise chain of events is never consistent, > predictable, nor triggered in any particular temporal relation > to when MOH is last used--at least, not one that I can pin down. > It does not appear to arise immediately following the activation > of a MOH sequence.We had the same problem on our Asterisk ACD. After switching to native mode of MOH, problem goes away.