For the last several days-- I guess ever since I rebooted into the latest kernel (running Centos 5.3 32-bit) -- I have had a bizarre CPU usage plot (attached).

Disk I/O is normal, network traffic shows slightly elevated but nothing is showing up in any logs to indicate any malicious activity, and the system is generally pretty responsive. I do have a "heartbeat" script that sends me a text message every 30 minutes with the output of "uptime" and the load average peaks at around 2.5.

I checked Cron for anything that runs at 8-hour intervals (or at the times shown on the plot) but I can't find anything that would account for this.

I'm wondering if anyone else is seeing anything similar, or might have any idea where to look for answers? It's not impacting performance (that I've noticed-- and since VoIP runs through this box it's pretty load-sensitive) but I'd like to figure out a potential cause.

I am on atlanta51.

Well, after much more research, it appears to be a problem with mpg123, which is used by Asterisk for music on hold. I can't explain why this is suddenly happening, but running a "killall mpg123" will drop the CPU utilization back down. Since this (fortunately) doesn't cause any significant interruption to the MOH, nor any dropped calls, I simply put the "killall mpg123" in a Cron job to run every 30 minutes.

Not a fix... and not an explanation for why the problem's suddenly happening... but it's a satisfactory workaround.

Which version of Asterisk are you running? Pretty much any recent version (within the past few years) should have its own internal handler for MP3 hold music (format_mp3). Might also be worth pre-converting them into your most common codec(s) instead.

'course, if you're not using static hold music files but are streaming, you're probably boned

FreePBX 2.5.1 + Asterisk 1.4.25.1.

Yes, the music is streaming.

I did make one other change which I wouldn't have thought would make a difference, but apparently it does.

Originally I had the streaming MOH defined directly in the config files. However, the MOH feeds weren't appearing in the dropdowns in FreePBX (as they had in previous FreePBX installs on other boxes). I moved the streaming MOH definitions to the Music on Hold section of the FreePBX GUI, and THAT appears to be where things are working differently.

The way I was doing it, which is widely published online, mpg123 is apparently halted when no calls are using that MOH stream. When a new call connects, about 10 seconds of buffered audio is played, and then the call stream jumps to the actual live streaming content. Not elegant, but it works, and didn't seem to cause any load issues.

With the new method, apparently the system keeps mpg123 running continuously and there must be a glitch in mpg123 that becomes evident with continuous operation, which I wasn't seeing under the old method.

I'm not sure but i went to your site and it said

"
* You have accessed a private computer system. All activity on this *
* system is logged. Unauthorized access is forbidden and will be *
* prosecuted to the fullest extent of the law. *
* *
* Members of the SKYWARN Amateur Radio Support Team wishing to gain.
"

Then i closed it. I hope your not going to go after me...