On Sun, Sep 15, 2019, at 2:21 AM, Michael Maier wrote: > Hello! Kia ora, > Since Asterisk 16.5.x (without any additional patch at all), I' m > seeing continuously rising memory consumption each hour even if there > where no calls at all. It's about > 792 kbytes (RSS) each hour (3 SIPS / TLS 1.2 trunks, 10 min > ReRegistration, 240 s OPTIONS, 1 SIPS trunk, 60 s ReRegistration, 2 SIP > extensions) > > Therefore I tested different scenarios: > > Asterisk 16.4.1 -> no memory leak > Asterisk 16.5.1 -> memory leak > > Asterisk 16.4.1 with pjsip 4.9 -> memory leak > Asterisk 16.5.1 with pjsip 4.8 -> no memory leak > > > Therefore, I can say, that there is a problem related to pjsip 4.9 > (maybe it's a pjsip problem itself or Asterisk should have been changed > to adopt new behavior of pjsip 4.9). > > Anyway: Asterisk is quite unusable since 16.5.x. 2 times I already > encountered the OOM killer reaping an asterisk 16.5.x process consuming > far too much memory.
Recently two issues were created[1][2] dealing with memory leaks and Kevin Harwell is actively trying to narrow down what is happening. If you believe one is related then any additional information or details you can provide on it would be appreciated, such as your PJSIP version finding. > > > BTW: I'm not really happy with the fact, that an existing LTS / stable > version gets a new pjsip version "on the fly". From my point of view, > this should have been done > during a normal development cycle and not during a stable phase. Since support for bundled PJSIP we've actively tried to keep up to date, so that we don't end up managing a fork and backporting a lot of patches. This has worked well for us and we haven't seen any problems - in fact we've gained some stability at times. If this is a problem in PJSIP this would be the first time we've encountered a regression. If people feel that we should instead lock versions then this is certainly something we can discuss. What do others think? I'd also urge everyone reading this to consider testing the release candidates we release in different environments so we can uncover things quicker. The more testing of those we can get the better actual releases will be and it's a great way to help the project. [1] https://issues.asterisk.org/jira/browse/ASTERISK-28521 [2] https://issues.asterisk.org/jira/browse/ASTERISK-28523 -- Joshua C. Colp Digium - A Sangoma Company | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
