<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><tt>Resolution here: it seems the recently added {ip.matches}
transformation was<br>
leaking pkg memory. Fixed on latest 3.0 and master [1].</tt></p>
<p><tt>Enjoy,</tt></p>
<p><tt>[1]: </tt><tt><a
href="https://github.com/OpenSIPS/opensips/commit/1c4fa53f2fab6">https://github.com/OpenSIPS/opensips/commit/1c4fa53f2fab6</a></tt></p>
<pre class="moz-signature" cols="72">Liviu Chircu
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/liviuchircu">www.twitter.com/liviuchircu</a> | <a class="moz-txt-link-abbreviated" href="http://www.opensips-solutions.com">www.opensips-solutions.com</a>
OpenSIPS Summit, Amsterdam, May 2020
<a class="moz-txt-link-abbreviated" href="http://www.opensips.org/events">www.opensips.org/events</a>
OpenSIPS Bootcamp, Miami, March 2020
<a class="moz-txt-link-abbreviated" href="http://www.opensips.org/training">www.opensips.org/training</a></pre>
<div class="moz-cite-prefix">On 20.01.2020 13:18, Callum Guy wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFjCFzn6vWe1Z=pCev4sMvAb+V6usm-5DRyYxhMgOXm_5P4LhA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hi Liviu,<br>
<div><br>
</div>
<div>Thanks for coming back to me. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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 <a
href="mailto:liviu@opensips.org" moz-do-not-send="true">liviu@opensips.org</a>
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.</div>
<div><br>
</div>
<div>Thanks in advance,</div>
<div><br>
</div>
<div>Callum</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, 20 Jan 2020 at 09:50,
Liviu Chircu <<a href="mailto:liviu@opensips.org"
target="_blank" moz-do-not-send="true">liviu@opensips.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi
Callum,<br>
<br>
Sorry for the late follow-up: did you make any progress with
your leak?<br>
If not, could you prepare a minimal opensips.cfg that exposes
the <br>
problem? A quick<br>
code review did not show any obvious leaks, so I suspect there
is something<br>
about your specific script that I am overlooking.<br>
<br>
Best regards,<br>
<br>
Liviu Chircu<br>
<a href="http://www.twitter.com/liviuchircu" rel="noreferrer"
target="_blank" moz-do-not-send="true">www.twitter.com/liviuchircu</a>
| <a href="http://www.opensips-solutions.com"
rel="noreferrer" target="_blank" moz-do-not-send="true">www.opensips-solutions.com</a><br>
<br>
OpenSIPS Summit, Amsterdam, May 2020<br>
<a
href="http://www.opensips.org/events/Summit-2020Amsterdam"
rel="noreferrer" target="_blank" moz-do-not-send="true">www.opensips.org/events/Summit-2020Amsterdam</a><br>
OpenSIPS Bootcamp, Miami, March 2020<br>
<a href="http://www.opensips.org/training" rel="noreferrer"
target="_blank" moz-do-not-send="true">www.opensips.org/training</a><br>
<br>
On 09.12.2019 13:13, Callum Guy wrote:<br>
> Hi All,<br>
><br>
> I wanted to follow up on a recent issue I experienced to
understand if<br>
> it was due to user error or a bug that needs to be
patched.<br>
><br>
> The issue was traced back to a simple function call in
the permissions module:<br>
><br>
> check_source_address(0, $avp(address_desc))<br>
><br>
> Nearly every request processed would have been an
unlisted source<br>
> address and a negative response would have been expected.
As an in<br>
> memory hash lookup for a small address list (<50
records) this seemed<br>
> like a very safe operation to perform.<br>
><br>
> The AVP is uninitialised at the point of invocation - I
am guessing<br>
> that this is key to the problem. To resolve the problem I
have simply<br>
> removed the AVP and the method call is now:<br>
><br>
> check_source_address(0)<br>
><br>
> I would like to learn whether using an AVP for this
operation was<br>
> incorrect or whether there was another reason for the
leak. I've had a<br>
> go at reviewing the source for permissions and pvar
however I quickly<br>
> got lost trying to find where the AVP initialisation
would have been<br>
> invoked. Any advice would be appreciated.<br>
><br>
> Many thanks,<br>
><br>
> Callum<br>
><br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank"
moz-do-not-send="true">Users@lists.opensips.org</a><br>
<a
href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote>
</div>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;text-align:justify"><font
size="3" face="Verdana"><span
style="font-size:8px;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"></span></font></p>
<div><img
src="https://www.x-on.co.uk/email/footer/General-Practice-Awards-winners.jpg"
moz-do-not-send="true"></div>
<div><br>
</div>
<div>
<div>
<div><font size="4"><b><sup><font face="Verdana">0333 332
0000 | <a href="http://www.x-on.co.uk"
target="_blank" moz-do-not-send="true">www.x-on.co.uk</a>
| <sub> </sub></font></sup></b></font><font
size="4"><b><sub><sup><font face="Verdana"><a
href="https://www.linkedin.com/company/x-on"
target="_blank" moz-do-not-send="true"><img
src="http://www.x-on.co.uk//images/icon/linkedin.png"
moz-do-not-send="true" width="24" height="24"></a>
<a href="https://www.facebook.com/XonTel"
target="_blank" moz-do-not-send="true"><img
src="http://www.x-on.co.uk//images/icon/facebook.png"
moz-do-not-send="true" width="24" height="24"></a>
<a href="https://twitter.com/xonuk"
target="_blank" moz-do-not-send="true"><img
src="http://www.x-on.co.uk//images/icon/twitter.png"
moz-do-not-send="true" width="24" height="24"></a></font></sup></sub> </b></font><br>
<p><span
style="font-size:6.0pt;font-family:Verdana;color:black">X-on
is a trading name of Storacall Technology Ltd a limited
company registered in
England and Wales.<br>
Registered Office : Avaland House, 110 London Road,
Apsley, Hemel Hempstead,
Herts, HP3 9SD. Company Registration No. 2578478.<br>
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 <span>+44(0)333 332 0000</span>
and delete the<br>
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. </span><span
style="font-size:6.0pt;font-family:Verdana;color:black">Views
or opinions expressed by an individual<br>
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<br>
for
viruses. X-on makes no representation or warranty as to
the absence of viruses
in this email or any attachments.</span></p>
<p><span
style="font-size:6.0pt;font-family:Verdana;color:black"></span><font
size="2"><span
style="font-size:6.0pt;font-family:Verdana;color:black"></span></font></p>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
</body>
</html>