[asterisk-bugs] [JIRA] (ASTERISK-25655) core taskprocessors sorcery-control memory not cleared

[Rusty Newton (JIRA)]

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

Rusty Newton commented on ASTERISK-25655:
-----------------------------------------

Linking to ASTERISK-25683 that Yaron opened in regards to the MALLOC_DEBUG issue.

> core taskprocessors sorcery-control memory not cleared
> ------------------------------------------------------
>
>                 Key: ASTERISK-25655
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25655
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/Sorcery, Core/Stasis
>    Affects Versions: 13.6.0, 13.7.0
>            Reporter: yaron nahum
>            Assignee: Unassigned
>         Attachments: asterisk_13.7_mem_sum_before_problem.txt, J7_IVR_astersik_extensions_ael.txt, J7_IVR_astersik_messages-2016-1-3.txt, J7_IVR_astersik_top_log-2016-1-3.txt, J7_IVR_astersik_uptime_log-2016-1-3.txt, J7_IVR_server_props.txt, sorcery-control_mem_leak.txt
>
>
> production env is running with pjsip.
> after 2-3 days the memory on the machine is raises rapidly to around 85% (4G ram).asterisk start responding slowly and when "core show taskprocessors" output shows high In Queue allocation for "sorcery" somethimes "sorcery-control" and even "stasis-core-control".
> in the case here the sorcery-control queue is high.
> Further detail:
> The issue started at 13.6 and was not solved at 13.7. before that we had 13.2 and no issue.
> I do not understand why it happens. there is no clear pattern. the issue started 15-16 days after installing the first 13.6 server. On another server (we have 7 with 13.7) it started 3 hours after installing 13.7.
> The asterisk server handles around 13000 calls per day. We use PJSIP, very little ODBC queries to mysql DB. (the extensions.ael attached).  We have Kamailio in front of the asterisk and in some cases it redirects the call back to the asterisk using 302 to another extension.
> The application is compiled with DONT_OPTIMIZE and BETTER_BACKTRACES flags. And no other "special" installation.
> I do not see something special in the logs other then some warning about the ael script (fixed :-)),
> PJSIP and dial unable to frame type...
> and one exactly for the taskprocessor that reached 500 tasks "task processor queue reached 500 scheduled tasks"
> The files attached are the AEL, the messages log, the server top and uptime log and the server VMware properties.



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