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 li...@opensips.org <mailto:li...@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 <li...@opensips.org
<mailto:li...@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@lists.opensips.org <mailto:Users@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@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
