[OpenSIPS-Users] Memory leak - solved
Liviu Chircu
liviu at opensips.org
Mon Jan 20 09:35:33 EST 2020
Resolution here: it seems the recently added {ip.matches} transformation was
leaking pkg memory. Fixed on latest 3.0 and master [1].
Enjoy,
[1]: https://github.com/OpenSIPS/opensips/commit/1c4fa53f2fab6
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com
OpenSIPS Summit, Amsterdam, May 2020
www.opensips.org/events
OpenSIPS Bootcamp, Miami, March 2020
www.opensips.org/training
On 20.01.2020 13:18, Callum Guy wrote:
> Hi Liviu,
>
> Thanks for coming back to me.
>
> I am continuing to have memory problems on these servers however I
> have stemmed the flow as per my previous emails here. I am still in an
> uncomfortable position where the systems need to be restarted weekly
> so I'd like to get this resolved as soon as possible.
>
> To provide a very quick rundown of the history, this is a new
> registrar as part of our migration to v3. The instances run in
> clustered pairs in hot-standby (full-sharing) using a shared database.
> Initially I didn't notice the issue as I had excessive memory
> allocated to each process (8GB!) however as more UACs were migrated we
> eventually exhausted this. The first step was to simply respond to
> handset NOTIFY pings at the start of the script which prevented all
> routes executing and bypassing the leak. After this I noticed
> memory usage continuing to grow and applied the patch described above
> which helped to further reduce the leak indicating that the change was
> relevant however there is something else there.
>
> As a production instance I am currently looking into deploying a
> development server to allow me to dig deeper into the problem however
> it would be great if you could take a look at my config - that would
> be very much welcomed. Would you like me to send you a complete config
> to liviu at opensips.org <mailto:liviu at opensips.org> directly? If you'd
> prefer for me to trim it then I can remove what I think are irrelevant
> sections however I'm concerned that I might trim something that would
> be helpful in your review, just let me know what you would prefer and
> any other details that could be useful.
>
> Thanks in advance,
>
> Callum
>
>
> On Mon, 20 Jan 2020 at 09:50, Liviu Chircu <liviu at opensips.org
> <mailto:liviu at opensips.org>> wrote:
>
> Hi Callum,
>
> Sorry for the late follow-up: did you make any progress with your
> leak?
> If not, could you prepare a minimal opensips.cfg that exposes the
> problem? A quick
> code review did not show any obvious leaks, so I suspect there is
> something
> about your specific script that I am overlooking.
>
> Best regards,
>
> Liviu Chircu
> www.twitter.com/liviuchircu <http://www.twitter.com/liviuchircu> |
> www.opensips-solutions.com <http://www.opensips-solutions.com>
>
> OpenSIPS Summit, Amsterdam, May 2020
> www.opensips.org/events/Summit-2020Amsterdam
> <http://www.opensips.org/events/Summit-2020Amsterdam>
> OpenSIPS Bootcamp, Miami, March 2020
> www.opensips.org/training <http://www.opensips.org/training>
>
> On 09.12.2019 13:13, Callum Guy wrote:
> > Hi All,
> >
> > I wanted to follow up on a recent issue I experienced to
> understand if
> > it was due to user error or a bug that needs to be patched.
> >
> > The issue was traced back to a simple function call in the
> permissions module:
> >
> > check_source_address(0, $avp(address_desc))
> >
> > Nearly every request processed would have been an unlisted source
> > address and a negative response would have been expected. As an in
> > memory hash lookup for a small address list (<50 records) this
> seemed
> > like a very safe operation to perform.
> >
> > The AVP is uninitialised at the point of invocation - I am guessing
> > that this is key to the problem. To resolve the problem I have
> simply
> > removed the AVP and the method call is now:
> >
> > check_source_address(0)
> >
> > I would like to learn whether using an AVP for this operation was
> > incorrect or whether there was another reason for the leak. I've
> had a
> > go at reviewing the source for permissions and pvar however I
> quickly
> > got lost trying to find where the AVP initialisation would have been
> > invoked. Any advice would be appreciated.
> >
> > Many thanks,
> >
> > Callum
> >
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> *^0333 332 0000 | www.x-on.co.uk <http://www.x-on.co.uk> |
> _**_^<https://www.linkedin.com/company/x-on>
> <https://www.facebook.com/XonTel> <https://twitter.com/xonuk> *
>
> X-on is a trading name of Storacall Technology Ltd a limited company
> registered in England and Wales.
> Registered Office : Avaland House, 110 London Road, Apsley, Hemel
> Hempstead, Herts, HP3 9SD. Company Registration No. 2578478.
> The information in this e-mail is confidential and for use by the
> addressee(s) only. If you are not the intended recipient, please
> notify X-on immediately on +44(0)333 332 0000 and delete the
> message from your computer. If you are not a named addressee you must
> not use, disclose, disseminate, distribute, copy, print or reply to
> this email. Views or opinions expressed by an individual
> within this email may not necessarily reflect the views of X-on or its
> associated companies. Although X-on routinely screens for viruses,
> addressees should scan this email and any attachments
> for viruses. X-on makes no representation or warranty as to the
> absence of viruses in this email or any attachments.
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200120/1febec39/attachment-0001.html>
More information about the Users
mailing list