[asterisk-bugs] [JIRA] (ASTERISK-23627) Asterisk CPU usage is 100%
Matt Jordan (JIRA)
noreply at issues.asterisk.org
Mon Apr 14 07:15:19 CDT 2014
[ https://issues.asterisk.org/jira/browse/ASTERISK-23627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217288#comment-217288 ]
Matt Jordan commented on ASTERISK-23627:
----------------------------------------
Thanks for your comments. This does not appear to be a bug report and we are closing it. We appreciate the difficulties you are facing, but it would make more sense to raise your question in the support tracker, http://www.asterisk.org/support.
> Asterisk CPU usage is 100%
> --------------------------
>
> Key: ASTERISK-23627
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-23627
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Environment: CentOS
> Reporter: preeti saini
> Severity: Critical
>
> Dear All,
> We are using asterisk-1.8,5.0 on our CentOS machine. Everytime our asterisk crashed because of 100% CPU usage. We did lot of analysis, but enable to track the issue.
> We run this command "# ps -LlFm -p `pidof asterisk`" to check 100%CPU usage of each asterisk thread and below is the output:
> F S UID PID PPID LWP C NLWP PRI NI ADDR SZ WCHAN RSS PSR STIME TTY TIME CMD
> 4 - root 29661 29659 - 0 43 - - - 863265 - 27168 - 09:43 pts/1 00:00:01 /usr/sbin/asterisk -f -vvvg -c
> 4 S root - - 29661 0 - 80 0 - - n_tty_ - 5 09:43 - 00:00:00 -
> 1 S root - - 29662 0 - 80 0 - - inotif - 4 09:43 - 00:00:00 -
> 1 S root - - 29663 0 - 80 0 - - futex_ - 0 09:43 - 00:00:00 -
> 1 S root - - 29664 0 - 80 0 - - poll_s - 0 09:43 - 00:00:00 -
> 1 S root - - 29665 0 - 80 0 - - futex_ - 5 09:43 - 00:00:00 -
> 1 S root - - 29666 0 - 80 0 - - futex_ - 5 09:43 - 00:00:00 -
> 1 S root - - 29667 0 - 80 0 - - futex_ - 2 09:43 - 00:00:00 -
> 1 S root - - 29668 0 - 80 0 - - poll_s - 4 09:43 - 00:00:00 -
> 1 S root - - 29669 0 - 80 0 - - futex_ - 7 09:43 - 00:00:00 -
> 1 S root - - 29670 0 - 80 0 - - futex_ - 4 09:43 - 00:00:00 -
> 1 S root - - 29671 0 - 80 0 - - futex_ - 5 09:43 - 00:00:00 -
> 1 S root - - 29672 0 - 80 0 - - futex_ - 5 09:43 - 00:00:00 -
> 1 S root - - 29673 0 - 80 0 - - futex_ - 4 09:43 - 00:00:00 -
> 1 S root - - 29674 0 - 80 0 - - futex_ - 5 09:43 - 00:00:00 -
> 1 S root - - 29675 0 - 80 0 - - futex_ - 5 09:43 - 00:00:00 -
> 1 S root - - 29676 0 - 80 0 - - futex_ - 5 09:43 - 00:00:00 -
> 1 S root - - 29677 0 - 80 0 - - futex_ - 6 09:43 - 00:00:00 -
> 1 S root - - 29678 0 - 80 0 - - futex_ - 5 09:43 - 00:00:00 -
> 1 S root - - 29679 0 - 80 0 - - futex_ - 6 09:43 - 00:00:00 -
> 1 S root - - 29680 0 - 80 0 - - futex_ - 7 09:43 - 00:00:00 -
> 1 S root - - 29681 0 - 80 0 - - futex_ - 5 09:43 - 00:00:00 -
> 1 S root - - 29682 0 - 80 0 - - futex_ - 6 09:43 - 00:00:00 -
> 1 S root - - 29683 0 - 80 0 - - futex_ - 5 09:43 - 00:00:00 -
> 1 S root - - 29684 0 - 80 0 - - futex_ - 6 09:43 - 00:00:00 -
> 1 S root - - 29685 0 - 80 0 - - futex_ - 5 09:43 - 00:00:00 -
> 1 S root - - 29686 0 - 80 0 - - poll_s - 5 09:43 - 00:00:00 -
> 1 S root - - 29687 0 - 80 0 - - poll_s - 5 09:43 - 00:00:00 -
> 1 S root - - 29688 0 - 80 0 - - poll_s - 0 09:43 - 00:00:00 -
> 1 S root - - 29689 0 - 80 0 - - poll_s - 1 09:43 - 00:00:00 -
> 1 S root - - 29690 0 - 80 0 - - poll_s - 0 09:43 - 00:00:00 -
> 1 S root - - 29691 0 - 80 0 - - inet_c - 5 09:43 - 00:00:00 -
> 1 S root - - 29692 0 - 80 0 - - poll_s - 0 09:43 - 00:00:00 -
> 1 S root - - 29693 0 - 80 0 - - poll_s - 2 09:43 - 00:00:00 -
> 1 S root - - 29694 0 - 80 0 - - hrtime - 2 09:43 - 00:00:00 -
> 1 S root - - 29695 0 - 80 0 - - hrtime - 5 09:43 - 00:00:00 -
> 1 S root - - 29696 0 - 80 0 - - futex_ - 5 09:43 - 00:00:00 -
> 1 S root - - 29697 0 - 80 0 - - hrtime - 5 09:43 - 00:00:00 -
> 1 S root - - 29698 0 - 80 0 - - poll_s - 5 09:43 - 00:00:00 -
> 1 S root - - 29699 0 - 80 0 - - hrtime - 5 09:43 - 00:00:00 -
> 1 S root - - 29700 0 - 80 0 - - poll_s - 5 09:43 - 00:00:00 -
> 1 S root - - 29701 0 - 80 0 - - poll_s - 6 09:43 - 00:00:00 -
> 1 S root - - 29702 0 - 80 0 - - futex_ - 6 09:43 - 00:00:00 -
> 1 S root - - 29703 0 - 80 0 - - poll_s - 5 09:43 - 00:00:00 -
> After that, we run command "# pstack `pidof asterisk` > /tmp/asterisk.stack.txt" to check the stack state of process and here is the output:
> Thread 21 (Thread 0x7f2fface5700 (LWP 27363)):
> #0 0x00000038398cf527 in sched_yield () from /lib64/libc.so.6
> #1 0x00007f30142c6b56 in __sip_autodestruct () from /usr/lib/asterisk/modules/chan_sip.so
> #2 0x00000000005207f6 in ast_sched_runq ()
> #3 0x00007f30142e7ee7 in do_monitor () from /usr/lib/asterisk/modules/chan_sip.so
> #4 0x0000000000536f2a in dummy_start ()
> #5 0x0000003839c079d1 in start_thread () from /lib64/libpthread.so.0
> #6 0x00000038398e8b6d in clone () from /lib64/libc.so.6
> I didn't understand where exactly the problem is.
> I also read in google that 100% could be result of corrupt database astdb file.
> Can anybody help in resolving this issue.That would be great help.Thanls.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list