I don’t know 
But people has asked me this a couple of times lately and my answer is always “I don’t know”. However ps can give you more information about it. In fact, this works for any application you have and you want to debug why is going crazy.
First, check which thread (Asterisk is a multi threaded application) is going crazy.
# ps -LlFm -p `pidof asterisk`
That should show you the % of CPU being used by each Asterisk thread in the column named “C”, then write down the LWP colum value for the thread you are interested on. (LWP is a light weight process number, roughly speaking, the thread id). Now that you have the thread id, you need to know what that thread is doing.
# pstack `pidof asterisk` > /tmp/asterisk.stack.txt
That will cause the asterisk process to dump the stack state to the /tmp/asterisk.stack.txt file. If you don’t have the pstack command google for it, I think in CentOS is as easy as yum install pstack.
Then open the file and search for the LWP that you just wrote down. Hopefully you will find some hints that let you know how to avoid it or at least a lot more information to post in bugs.digium.com
UPDATE:
One of the guys who asked this question later told me what he found:
Thread 10 (Thread 0×41d8f940 (LWP 3406)):
#0 0×00000033ce2ca436 in poll () from /lib64/libc.so.6
#1 0×00000000004933c0 in ast_io_wait ()
#2 0×00002aaabd9510cd in network_thread ()
#3 0×00000000004f8b2c in dummy_start ()
#4 0×00000033cee06367 in start_thread () from /lib64/libpthread.so.0
#5 0×00000033ce2d2f7d in clone () from /lib64/libc.so.6
A quick grep -rI “network_thread” in the Asterisk source code reveals this function belongs to chan_iax.c, disabling chan_iax.so in modules.conf is a good workaround to his problem, however further debugging would be needed to determine why the monitor thread is looping like that.
Ubuntu 9.10 does not have pstack. It’s not in the Karmic repository, so doing an “apt-get install pstack” failed to find the package.
Yet another reason to not use Ubuntu.
Much thanks!
Thread 13 (Thread 0xb6e74b90 (LWP 3128)):
#0 0xf57fe416 in __kernel_vsyscall ()
#1 0×4e0969d1 in select () from /lib/libc.so.6
#2 0xb6ecdbb9 in ooSocketSelect () from /usr/lib/asterisk/modules/chan_ooh323.so
#3 0xb6ebaa35 in ooH2250Receive () from /usr/lib/asterisk/modules/chan_ooh323.so
#4 0xb6ebb418 in ooProcessFDSETsAndTimers () from /usr/lib/asterisk/modules/chan_ooh323.so
#5 0xb6ebb74e in ooMonitorChannels () from /usr/lib/asterisk/modules/chan_ooh323.so
#6 0xb6fba2a7 in ooh323c_stack_thread () from /usr/lib/asterisk/modules/chan_ooh323.so
#7 0×0810071b in dummy_start ()
#8 0×4e1d4832 in start_thread () from /lib/libpthread.so.0
#9 0×4e09de0e in clone () from /lib/libc.so.6
One possible reason to spin like crazy in select()-based systems is having more than 1024 file descriptors in the process. (increasing limit with ulimit -n does not help and in fact may do things worst).
So:
Thread 13 (Thread 0xb6e73b90 (LWP 1724)):
#0 0xf57fe416 in __kernel_vsyscall ()
#1 0×4e0969d1 in select () from /lib/libc.so.6
#2 0xb6eccbb9 in ooSocketSelect () from /usr/lib/asterisk/modules/chan_ooh323.$
#3 0xb6eb9a35 in ooH2250Receive () from /usr/lib/asterisk/modules/chan_ooh323.$
#4 0xb6eba418 in ooProcessFDSETsAndTimers () from /usr/lib/asterisk/modules/ch$
#5 0xb6eba74e in ooMonitorChannels () from /usr/lib/asterisk/modules/chan_ooh3$
#6 0xb6fb92a7 in ooh323c_stack_thread () from /usr/lib/asterisk/modules/chan_o$
#7 0×0810071b in dummy_start ()
#8 0×4e1d4832 in start_thread () from /lib/libpthread.so.0
#9 0×4e09de0e in clone () from /lib/libc.so.6
Now what?
Now you either:
- disable the module
- fix the module
- pay someone to fix the module
I fixed the module by actually configuring it to do nothing. By default there is a mypeer1 and myfriend1 configured which I commented out. I also added my servers IP.
For the last 10 hours it hasn’t been acting up, so if I don’t post again, it is fixed.
Good news
It’s fixed – no CPU usage alerts thus far. For future reference this was in the h323.conf / ooh323.conf where I fixed the settings. After that did an asterisk -rx ‘restart now’ and issue has not recurred. I guess this is all caused because I ran asterisk make samples during install.