[Home]

Summary:ASTERISK-27281: Increased memory usage when using Sorcery Caching
Reporter:Bill Brigden (billbrigden)Labels:
Date Opened:2017-09-20 06:41:15Date Closed:2018-03-12 08:20:22
Priority:MajorRegression?
Status:Closed/CompleteComponents:
Versions:13.14.0 Frequency of
Occurrence
Constant
Related
Issues:
duplicatesASTERISK-27679 res_pjsip: Endpoint destruction does not free DTLS configuration
Environment:Debian 8.7Attachments:( 0) mem2.PNG
Description:When using Sorery enabled with config like:

{noformat}
[res_pjsip]

endpoint/cache=memory_cache,object_lifetime_stale=600,object_lifetime_maximum=1800,expire_on_reload=yes,maximum_objects=500
endpoint=realtime,ps_endpoints
endpoint=config,pjsip.conf,criteria=type=endpoint

auth/cache=memory_cache,object_lifetime_stale=600,object_lifetime_maximum=1800,expire_on_reload=yes,maximum_objects=500
auth=realtime,ps_auths

aor/cache=memory_cache,object_lifetime_stale=600,object_lifetime_maximum=1800,expire_on_reload=yes,maximum_objects=500
aor=realtime,ps_aors
aor=config,pjsip.conf,criteria=type=aor

domain_alias=realtime,ps_domain_aliases
contact=realtime,ps_contacts
{noformat}

I've seen increasing memory usage until the server runs out of memory (and swap). If I comment out the "/cache" lines - memory usage stays relatively stable.

Happy to collate logs / info however would appreciate guidance on what is required to diagnose the cause of unreleased memory.

I'll upload a screenshot of my collectd graphing post-creation
Comments:By: Asterisk Team (asteriskteam) 2017-09-20 06:41:17.114-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: Bill Brigden (billbrigden) 2017-09-20 06:43:32.948-0500

This shows physical memory usage over the last few months - the spikes are where the asterisk process is restarted

By: Richard Mudgett (rmudgett) 2017-09-20 07:35:16.357-0500

These wiki pages talk about what is needed to help find memory leaks:
https://wiki.asterisk.org/wiki/display/AST/Memory+Leak+Debugging
https://wiki.asterisk.org/wiki/display/AST/MALLOC_DEBUG+Compiler+Flag

You may want to upgrade to the latest v13 release to see if the memory leak has already been fixed.

By: Asterisk Team (asteriskteam) 2017-10-04 12:00:01.131-0500

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines

By: Bill Brigden (billbrigden) 2018-03-12 08:19:16.009-0500

FYI - this can now be marked as resolved+fixed - it was fixed by the recent commit reported on case ASTERISK-27679 (which had linked here):

{noformat}
* res_pjsip: Endpoint destruction does not free DTLS configuration
 ASTERISK-27679 #close
 Reported by: Mak Dee
{noformat}

By: Asterisk Team (asteriskteam) 2018-03-12 08:19:16.768-0500

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.