[SR-Users] DMQ mem leak issues

Joel Serrano joel at textplus.com
Tue Sep 4 20:48:35 CEST 2018


Hi Charles,

I'm trying to move _away_ from database for data replication and pass over
to DMQ as much as possible, currently I have db_mode=1 for usrloc so that
is why I asked.

If I understand correctly, on a 2 node cluster, without database for usrloc
and only using DMQ, as long as both nodes don't go down at the same time
you are good... it would be possible to restart the nodes sequentially and
not lose registration info as they would replicate to each other on
startup, right?

Do you see a need for the database (specifically talking about usrloc
replication) other than persistency if *all* nodes in the dmq cluster are
down at the same time?

Thanks,
Joel.

On Tue, Sep 4, 2018 at 11:35 AM, Charles Chance <
charles.chance at sipcentric.com> wrote:

> Hi Joel,
>
> I have not had much time recently to find the cause of the issue with
> db_mode 1, although I should have some more time over the next couple of
> weeks.
>
> Out of interest, what will you be using the database for?
>
> Cheers,
>
> Charles
>
>
> On Fri, 24 Aug 2018 at 04:00, Joel Serrano <joel at textplus.com> wrote:
>
>> I’m planning to use DMQ + usrloc too! Thanks for sharing the solution!
>>
>> Do you know if It’s fixed also with db_mode=1?
>>
>>
>> On Thu, Aug 23, 2018 at 13:53 Julien Chavanton <jchavanton at gmail.com>
>> wrote:
>>
>>> Hi, I have glad you guys found a solution.
>>>
>>> Thanks for sharing it.
>>>
>>> Regards,
>>> Julien
>>>
>>> On Wed, Aug 22, 2018, 21:43 Rogelio Perez <rogelio at telnyx.com> wrote:
>>>
>>>> Hi Julien,
>>>>
>>>> Thanks for checking on this.
>>>> I've been working in the background with Charles on this issue and we
>>>> think we've found a solution, although the cause isn't clear to me yet.
>>>> Following Charles advice we changed the usrloc module parameter db_mode
>>>> from 1 (Write-Through) to 2 (Write-Back) and there's been no more memory
>>>> leaks incidents since then.
>>>> I'll report back if we have any further updates.
>>>>
>>>> Best,
>>>> Rogelio
>>>>
>>>>
>>>> On Wed, Aug 22, 2018 at 11:39 AM Julien Chavanton <jchavanton at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Rogerio, did you have any luck digging this leak further ?
>>>>>
>>>>> On Wed, Aug 8, 2018 at 3:37 AM Charles Chance <
>>>>> charles.chance at sipcentric.com> wrote:
>>>>>
>>>>>> Hi Rogelio,
>>>>>>
>>>>>> I have been running master on a three-node lab (one primary, two
>>>>>> secondary) for the past 24 hours or so, maintaining 2000 registrations on
>>>>>> the primary, replicating to both secondaries, and memory usage has remained
>>>>>> constant throughout.
>>>>>>
>>>>>> I will leave it running for another 24 hours to be sure but in the
>>>>>> meantime, you mentioned you are loading records from DB - which mode are
>>>>>> you using for writing (write-through or write-back)? Do you experience the
>>>>>> same symptoms if you disable the database completely on the secondary nodes
>>>>>> (or just one for testing) and instead, enable sync in dmq_usrloc?
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Charles
>>>>>>
>>>>>>
>>>>>> On 7 August 2018 at 16:42, Julien Chavanton <jchavanton at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I wonder if this could be introduced by a regression or if you are
>>>>>>> facing a specific edge case
>>>>>>>
>>>>>>> I briefly looked at the commits of DMQ and DMQ_USRLOC
>>>>>>> It seems there was significant work done.
>>>>>>> I would give a try with 5.0.0 and then we will at least learn that
>>>>>>> this is not a recent regression.
>>>>>>>
>>>>>>> On Mon, Aug 6, 2018 at 1:43 PM, Rogelio Perez <rogelio at telnyx.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Charles, Julien, Daniel,
>>>>>>>>
>>>>>>>> The results are pretty much the same, the mem leak is still there
>>>>>>>> and we need to restart Kamailio when it reaches certain threshold.
>>>>>>>> https://www.dropbox.com/s/enxx6b7t0c8vl49/Selection_539.png?dl=0
>>>>>>>>
>>>>>>>> Is there anything else we can try?
>>>>>>>> Will a core dump file tell us what's causing it?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Rogelio
>>>>>>>>
>>>>>>>> On Thu, Aug 2, 2018 at 2:57 PM Rogelio Perez <rogelio at telnyx.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Thanks Charles, it's working now.
>>>>>>>>> I'm deploying to production and confirming results soon.
>>>>>>>>>
>>>>>>>>> Rogelio
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> <https://telnyx.com>
>>>>>>>> Rogelio Perez | engineering | telnyx <https://telnyx.com>
>>>>>>>> chicago: +1 312 270 8119 | dublin: +353 1 912 6119
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Kamailio (SER) - Users Mailing List
>>>>>>>> sr-users at lists.kamailio.org
>>>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
>>>>>> office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
>>>>>> Birmingham Science Park, Birmingham B7 4BB.
>>>>>> _______________________________________________
>>>>>> Kamailio (SER) - Users Mailing List
>>>>>> sr-users at lists.kamailio.org
>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>
>>>>>
>>>>
>>>> --
>>>> <https://telnyx.com>
>>>> Rogelio Perez | engineering | telnyx <https://telnyx.com>
>>>> chicago: +1 312 270 8119 | dublin: +353 1 912 6119
>>>>
>>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
> --
> *Charles Chance*
> Managing Director
>
> t. 0330 120 1200    m. 07932 063 891
>
> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
> office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
> Birmingham Science Park, Birmingham B7 4BB.
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180904/19b3b726/attachment.html>


More information about the sr-users mailing list