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

[Dan Cropp (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-29775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Cropp updated ASTERISK-29775:
---------------------------------

    Attachment: messages
                confbridge.conf
                debug_log

The confbridge.conf is a probably not too important to this.  As I mentioned, we're using AMI to control most of the call flow and confbridges.  If a setting doesn't match what is required, we change the variable on the fly through AMI actions on the channel.

In the debug_log, at 11:24:30:434, we initiate the EXEC RECORD and this is when things spike.  
debug_log file shows "res_timing_timerfd.c: Expected to acknowledge 1 ticks but got 2 instead" happening regularly.
Even after the record completes dues to silence, the CPU remains high (ticks issue)..

I hangup the local channel that performed the recording at 11:24:48.712.
At this point, there are still the two ends of the other local channel.  Each end is in a different ConfBridge.
The ticks issue remains.

At 11:25:05.781, I perform the ConfBridgeKick to remove one end of the local channel from one of the ConfBridges.  At this point things are running much nicer.

I left a channel in the ConfBridge A, so it is continuing to process this portion even at the end of these logs.
The ConfBridge B is ended because there are no longer any channels remaining in it.

> 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
>            Assignee: Dan Cropp
>              Labels: confbridge
>         Attachments: confbridge.conf, debug_log, messages
>
>
> 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)