Summary: | ASTERISK-27281: Increased memory usage when using Sorcery Caching | ||||
Reporter: | Bill Brigden (billbrigden) | Labels: | |||
Date Opened: | 2017-09-20 06:41:15 | Date Closed: | 2018-03-12 08:20:22 | ||
Priority: | Major | Regression? | |||
Status: | Closed/Complete | Components: | |||
Versions: | 13.14.0 | Frequency of Occurrence | Constant | ||
Related Issues: |
| ||||
Environment: | Debian 8.7 | Attachments: | ( 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. |