[asterisk-bugs] [JIRA] (ASTERISK-29775) CPU spike

[Kevin Harwell (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-29775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257129#comment-257129 ] 

Kevin Harwell commented on ASTERISK-29775:
------------------------------------------

Sounds like you might have a scenario already setup. If so can you attach it to the issue?

Also, if you are able to easily replicate then please attach an Asterisk [debug log|https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information] (debug set to at least 5) as it could be helpful.

As well please attach the dialplan, and _confbridge.conf_ file(s) to this issue.

Thanks!

> CPU spike
> ---------
>
>                 Key: ASTERISK-29775
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29775
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_confbridge, Channels/chan_local
>    Affects Versions: 16.22.0, 18.8.0
>         Environment: Ubuntu 18 and also Ubuntu 20
>            Reporter: Dan Cropp
>            Severity: Major
>
> We use AMI to do the following.  I don't think it's AMI causing the issue, but mentioning it.
> Create 2 ConfBridges (A and B)
> Create a Local channel 1234.  
> Add one end of the local channel 1234;1 to ConfBridge A.
> Add the other end of local channel 1234;2 to ConfBridge B.
> Create another Local channel 5678.
> Add one end of local channel 5678;2 to ConfBridge B.
> Now on local channel 5678;1, we execute a Record.
> The CPU spikes at this point.  I suspect the code is in some loop with processing the multiple calls with the ConfBridge.
> Even when the Record completes, the CPU is still running 95+%.  The top PIDs are all asterisk running CPU% 95-96%, others four are 10-20%.
> Basically, the box becomes so bogged down it runs into problems and can't process other things.
> Even if I remove local channel 5678;2 from ConfBridge B, the CPU stays running at peak.
> Once either ConfBridge has the calls kicked or either end of the local channel 1234 is removed from either ConfBridge, the CPU issue is resolved.
> While local channels like this doesn't make sense.  We originally found this because we had PJSIP calls in different ConfBridges but needed the ConfBridges to be connected with a local channel.  All was fine until a customer started requiring us to have separate recording for each participant in one of the bridge.  That's when we started adding local channels as each participant joined and began recording.
> By eliminating the PJSIP calls in the sample, it eliminates areas to look at.



--
This message was sent by Atlassian JIRA
(v6.2#6252)