Summary:	ASTERISK-26914: Asterisk freezes for a few seconds under certain queue scenarios
Reporter:	Michael Gaudette (michael@virtutel.ca)	Labels:
Date Opened:	2017-04-01 07:49:14	Date Closed:	2017-04-02 19:43:13
Priority:	Critical	Regression?
Status:	Closed/Complete	Components:	CDR/General
Versions:	13.14.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	CentOS 5, 16GB of memory, 4 core CPU never gets high usage. I use mysql_cdr module	Attachments:
Description:	The way CDRs are recorded seem to create a problem when too many entries are associated to a channel. While it might be a generalized issue touching many modules, I am only aware of a way to reproduce it using queues. When the number of CDRs to be written (but not yet written to the DB - I use mysql_cdr) on a channel exceeds a specific number (it seems to be 5000 according to the error message) Asterisk won't take any SIP registrations and the SIP module (among possibly others) start acting up. It clears itself up within a minute or two. This scenario is easy to reproduce on my side: a queue, with ringall algorithm, 20 phones, all busy (on Do Not Disturb for example), 1 second between Ring attempts.  After about 250 seconds (5000 divided by 20) seconds of waiting what I described happens. I get this in the console: “taskprocessor_push: The 'subm:cdr_engine-00000003' task processor queue reached 5000 scheduled tasks again.” and at exactly the same time, a bunch of: "chan_sip.c: Autodestruct on dialog '1aec44fd134ae7b905e73cee1b14ab3e@23.23.23.23:5060' with owner SIP/MYPBX-00001d94 in place (Method: BYE). Rescheduling destruction for 10000 ms" This seems to be because while multiple CDR`s are written per queue call, it`s only done at the  end of the call, so CDRs accumulate in memory/cacher/whatever and break some arbitrary limit. In truth, even if there was no Asterisk arbitrary limit the fact that CDRs are not flushed would eventually overwhelmed system resources I imagine, so just upping the limit would not be a great fix. This is happening on an Asterisk 11 server that was upgraded to Asterisk 13. It did not happen on 11, but then again I am aware CDRs were drastically overhauled start Asterisk 12, specifically with multiple CDR per queue calls..
Comments:	By: Asterisk Team (asteriskteam) 2017-04-01 07:49:16.319-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Michael Gaudette (michael@virtutel.ca) 2017-04-02 14:28:21.613-0500 I believe you can close this ticket, as it was a misconfiguration issue/performance issue with writing those numerous entries to disk (csv AND sqlite3 were configured, even though I did not need either) and  not an actual asterisk bug. Very sorry about this. By: Rusty Newton (rnewton) 2017-04-02 19:43:14.028-0500 Thanks for following up and letting us know! I'll close it out.