[OpenSIPS-Users] disable_503_translation
Callum Guy
callum.guy at x-on.co.uk
Mon May 4 11:26:04 EST 2020
Hi Bogdan and others,
I've updated my runtime config to include the memory debug option (-a
Q_MALLOC_DBG) - its working great and I'm collecting data to try and
identify a potential leak.
Following this change I've noted a difference in the way processes are
being utilised. I'm running 20 UDP listeners and during normal
operation without the debugger I can see memory use growing on a
couple of processes which I've presumed means that the processes are
used in a top down order such that memory use remains relatively
static for most processes but grows on the processes which are being
most utilised. When the debugger is on however the load appears to be
evenly distributed amongst all processes so memory growth is even for
all 20 processes. As I'm hunting for a very minor leak it may be a few
weeks until I have enough information to identify memory growth. This
is actually very useful but I wanted to ask if this is an expected
behaviour when the debugger is enabled?
My base startup memory use per process is ~12.4Mb and I've copied in
some stats below to illustrate what I mean.
Without debugger, after a couple of days execution (notice process 23/21):
"pkmem:4-real_used_size": 12477048,
"pkmem:5-real_used_size": 12485184,
"pkmem:6-real_used_size": 12497672,
"pkmem:7-real_used_size": 12585320,
"pkmem:8-real_used_size": 12493296,
"pkmem:9-real_used_size": 12520400,
"pkmem:10-real_used_size": 12522488,
"pkmem:11-real_used_size": 12689832,
"pkmem:12-real_used_size": 12530056,
"pkmem:13-real_used_size": 12526160,
"pkmem:14-real_used_size": 12505896,
"pkmem:15-real_used_size": 12606136,
"pkmem:16-real_used_size": 12783888,
"pkmem:17-real_used_size": 12651568,
"pkmem:18-real_used_size": 12961944,
"pkmem:19-real_used_size": 12744784,
"pkmem:20-real_used_size": 12544880,
"pkmem:21-real_used_size": 13155584,
"pkmem:22-real_used_size": 12844256,
"pkmem:23-real_used_size": 13963040,
With debugger after 10 days of execution:
"pkmem:4-real_used_size": 12793624,
"pkmem:5-real_used_size": 12793872,
"pkmem:6-real_used_size": 12793400,
"pkmem:7-real_used_size": 12793552,
"pkmem:8-real_used_size": 12793560,
"pkmem:9-real_used_size": 12794872,
"pkmem:10-real_used_size": 12793952,
"pkmem:11-real_used_size": 12793488,
"pkmem:12-real_used_size": 12794328,
"pkmem:13-real_used_size": 12794016,
"pkmem:14-real_used_size": 12793664,
"pkmem:15-real_used_size": 12793832,
"pkmem:16-real_used_size": 12793464,
"pkmem:17-real_used_size": 12794240,
"pkmem:18-real_used_size": 12793792,
"pkmem:19-real_used_size": 12794072,
"pkmem:20-real_used_size": 12801088,
"pkmem:21-real_used_size": 12794264,
"pkmem:22-real_used_size": 12796232,
"pkmem:23-real_used_size": 12797184,
Thanks for reading, I am curious to understand more about what I'm seeing here.
On Tue, 28 Apr 2020 at 12:18, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:
>
> Just be sure you are not logging all the debug ops, but only the dump -
> in this case you should be safe .
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
> https://www.opensips-solutions.com
>
> On 4/28/20 1:21 PM, Callum Guy wrote:
> > OK will do, I've been hesitant to configure the debugger on a
> > production system in case it caused any performance/stability issues -
> > is that a reason for concern?
> >
> > For now I'll see if I can configure a test setup and see if I can
> > duplicate the problem there.
> >
> > Thanks for your time.
> >
> >
> > On Tue, 28 Apr 2020 at 10:01, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:
> >> Hi Callum,
> >>
> >> Maybe a better approach will be try to identify the potential leak as
> >> described here ->
> >> https://opensips.org/Documentation/TroubleShooting-OutOfMem
> >>
> >> Best regards,
> >>
> >> Bogdan-Andrei Iancu
> >>
> >> OpenSIPS Founder and Developer
> >> https://www.opensips-solutions.com
> >>
> >> On 4/28/20 1:38 AM, Callum Guy wrote:
> >>> Hi Bogdan,
> >>>
> >>> I'm still searching for my memory leak, just downgraded from 3.0.2 to
> >>> 3.0.1 and should be able to confirm if that has made a difference in a
> >>> day or two.
> >>>
> >>> During the hunt I've been reviewing the changelog commits - wondered
> >>> if you could check params var created at the link below:
> >>>
> >>> https://github.com/OpenSIPS/opensips/blob/559921962c69575bcdc90c1f03102e6d5c56d776/modules/dialog/dlg_req_within.c#L489
> >>>
> >>> My understanding of memory management in C isn't great but it looks to
> >>> be allocating without a free?
> >>>
> >>> Many thanks,
> >>>
> >>> Callum
> >>>
> >>>
> >>> On Fri, 24 Apr 2020 at 17:16, Callum Guy <callum.guy at x-on.co.uk> wrote:
> >>>> Thanks Bogdan, I realise it was a long shot! There are only minor differences between this and another system i am running so I'm going through eliminating the config differences.
> >>>>
> >>>> Version wise the stable one is 3.0.1 and the leaky one is 3.0.2
> >>>>
> >>>> Slow progress but I will get there eventually!
> >>>>
> >>>> On Fri, 24 Apr 2020, 16:50 Bogdan-Andrei Iancu, <bogdan at opensips.org> wrote:
> >>>>> Hi Callum,
> >>>>>
> >>>>> I 99.9999999999999999999% that that setting cannot generate a leak :)
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>> Bogdan-Andrei Iancu
> >>>>>
> >>>>> OpenSIPS Founder and Developer
> >>>>> https://www.opensips-solutions.com
> >>>>>
> >>>>> On 4/24/20 6:31 PM, Callum Guy wrote:
> >>>>>
> >>>>> Hi All,
> >>>>>
> >>>>> I've been hunting a minor memory leak in my config and wanted to check in with the devs in case it is related to ues of the parameter:
> >>>>>
> >>>>> disable_503_translation=yes
> >>>>>
> >>>>> Here is the implementation link to save you a few seconds:
> >>>>>
> >>>>> https://github.com/OpenSIPS/opensips/blob/7dd1151341b8229cd30e335b246e56938551f6bd/msg_translator.c#L2425
> >>>>>
> >>>>> Is there any chance that this is failing to free the tiny amount it's allocating on each use?
> >>>>>
> >>>>> All the best,
> >>>>>
> >>>>> Callum
> >>>>>
> >>>>>
> >>>>> 0333 332 0000 | x-on.co.uk | | Coronavirus
> >>>>>
> >>>>> THE ITSPA AWARDS 2020 AND Best ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks of the Internet Telephony Services Providers' Association, used under licence.
> >>>>>
> >>>>> 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
> >>>>>
> >>>>>
>
--
<https://www.x-on.co.uk/service/surgery-connect/coronavirus.htm>
*0333
332 0000 | x-on.co.uk <https://www.x-on.co.uk> | **
<https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel>
<https://twitter.com/xonuk> ** | Coronavirus
<https://www.x-on.co.uk/service/surgery-connect/coronavirus.htm>*
THE
ITSPA AWARDS 2020 <http://www.itspa.org.uk/itspa-awards> AND Best ITSP -
Mid Market, Best Software and Best Vertical Solution are trade marks of the
Internet Telephony Services Providers' Association, used under licence.
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.
More information about the Users
mailing list