Hi Pavel,<br><br>It might be netconsole thread.<br><br>If you are on debian based system like ubuntu, try removing -c parameter in /etc/init.d/asterisk from following line.<br><br>start-stop-daemon --start --oknodo --background --exec $DAEMON -- $ASTARGS -c<br>
<br>I have faced similar problem this worked for me, not sure if it will resolve your problem.<br><br>Thanks,<br><br>Anil<br><br><div class="gmail_quote">On Tue, Mar 16, 2010 at 3:28 PM, Pavel Troller <span dir="ltr"><<a href="mailto:patrol@sinus.cz">patrol@sinus.cz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi!<br>
I have a problem with one of Asterisk installations. It serves<br>
as a conference bridge and most of the time there is no traffic. When a new<br>
call arrives after a longer time of idleness, one of Asterisk threads awakes<br>
up and runs at 100% CPU utilization for a time, which is proportional to the<br>
time the system was idle before. For example, when there were two hours of<br>
idle, the thread runs about 3 seconds. When there was one week of idle, the<br>
thread runs several minutes. During this time, the Asterisk performance is<br>
degraded, including choppy playback of announcements and improper inband DTMF<br>
detection. It is on a 8-core machine, where using one core fully should not<br>
influence the total system performance. When the thread finishes its work,<br>
it's going to (almost) sleep again and Asterisk performance returns to normal.<br>
I can display the asterisk threads:<br>
bigmeat1*CLI> core show threads<br>
0x41b5e950 netconsole started at [ 1103] asterisk.c listener()<br>
0x40e33950 monitor_sig_flags started at [ 3527] asterisk.c main()<br>
0x4031e950 tps_processing_function started at [ 451] taskprocessor.c ast_taskprocessor_get()<br>
0x41cd1950 scan_thread started at [ 516] pbx_spool.c load_module()<br>
0x4205d950 do_monitor started at [20996] chan_sip.c restart_monitor()<br>
0x40ad7950 desc->accept_fn started at [ 462] tcptls.c ast_tcptls_server_start()<br>
0x4042a950 lock_broker started at [ 463] func_lock.c load_module()<br>
0x41c55950 do_monitor started at [ 3513] chan_mgcp.c restart_monitor()<br>
0x411bd950 do_timing started at [ 482] res_timing_pthread.c init_timing_thread()<br>
0x40fb4950 do_parking_thread started at [ 4589] features.c ast_features_init()<br>
0x413e7950 tps_processing_function started at [ 451] taskprocessor.c ast_taskprocessor_get()<br>
0x41906950 do_devstate_changes started at [ 751] devicestate.c ast_device_state_engine_init()<br>
0x41f76950 logger_thread started at [ 1009] logger.c init_logger()<br>
0x40932950 listener started at [ 1162] asterisk.c ast_makesocket()<br>
0x4188a950 tps_processing_function started at [ 451] taskprocessor.c ast_taskprocessor_get()<br>
0x41ae2950 canary_thread started at [ 3369] asterisk.c main()<br>
16 threads listed.<br>
I can display system threads:<br>
root@bigmeat1:~# ps axumw |less<br>
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND<br>
...<br>
root 3472 0.0 0.3 498956 15496 pts/1 - 08:23 0:04 /opt/asterisk/sbin/asterisk -p -f -I -vvvg -c<br>
root - 0.0 - - - - Sl 08:23 0:00 -<br>
root - 0.0 - - - - Sl 08:23 0:00 -<br>
root - 0.0 - - - - Sl 08:23 0:00 -<br>
root - 0.0 - - - - Sl 08:23 0:00 -<br>
root - 0.0 - - - - Sl 08:23 0:00 -<br>
root - 0.0 - - - - Sl 08:23 0:00 -<br>
root - 0.0 - - - - Sl 08:23 0:00 -<br>
root - 0.0 - - - - Sl 08:23 0:00 -<br>
root - 0.0 - - - - Sl 08:23 0:03 -<br>
root - 0.0 - - - - Sl 08:23 0:00 -<br>
root - 0.0 - - - - Sl 08:23 0:00 -<br>
root - 0.0 - - - - Sl 08:23 0:00 -<br>
root - 0.0 - - - - Sl 08:23 0:00 -<br>
root - 0.0 - - - - Sl 08:23 0:00 -<br>
root - 0.0 - - - - Sl 08:23 0:00 -<br>
root - 0.0 - - - - Sl 08:23 0:00 -<br>
root - 0.0 - - - - Sl 08:23 0:00 -<br>
As you can see, the Asterisk was started at 8:23, there was no call until<br>
10:30. Before the call, the main process showed 0:01 of CPU time, during<br>
the call, the time increased by 3 seconds (in the first 3 seconds of call)<br>
and then the time consumption returned to normal. You can also see an<br>
individual thread, which was at 0:00 before the call, and then promptly<br>
increased to 0:03 and also stopped. This thread is IMHO responsible for<br>
the problem.<br>
Can I map the threads displayed by ps to the ones shown by core show threads?<br>
Which thread could be the time-consuming one ? I've tested with internal timing<br>
(-I flag) as well as without it and there is no difference. DAHDI timer not<br>
used. The problem occurs during calls of any type, for example this one was to<br>
the Milliwatt application.<br>
It's Asterisk 1.6.1.7.<br>
With regards, Pavel.<br>
<font color="#888888"><br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</font></blockquote></div><br>