[OpenSIPS-Users] Quest to find memory leak
Răzvan Crainea
razvan at opensips.org
Tue Mar 7 04:39:07 EST 2017
So I understand that after ~3K calls, that process completely runs out
of memory?
How many calls have you done before this trace: http://pastebin.com/9Ge2NEVQ
Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com
On 03/07/2017 11:32 AM, John Nash wrote:
> when I check stats after a call attempt pkmem:7-free_size:: 3304280
>
> In this entry with every call I see a drop of 1000 bytes around and
> this never restores.
>
> On Tue, Mar 7, 2017 at 2:16 PM, Răzvan Crainea <razvan at opensips.org
> <mailto:razvan at opensips.org>> wrote:
>
> Hi, John!
>
> Again, this trace doesn't show any leak.
> Are you sure you are having a private memory leak and not a shared
> memory leak?
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutions
> www.opensips-solutions.com <http://www.opensips-solutions.com>
>
> On 03/06/2017 08:09 PM, John Nash wrote:
>> here is another trace
>> http://pastebin.com/9Ge2NEVQ
>>
>> I see lot of alloc request but no free.
>>
>> On Mon, Mar 6, 2017 at 6:57 PM, John Nash <john.nash778 at gmail.com
>> <mailto:john.nash778 at gmail.com>> wrote:
>>
>> Ok will try that. Is it possible that wrong usage of drouting
>> may cause this to happen instead of actual leak?... What are
>> the things private memory is used for?
>>
>> On Mon, Mar 6, 2017 at 6:48 PM, Răzvan Crainea
>> <razvan at opensips.org <mailto:razvan at opensips.org>> wrote:
>>
>> Hi, John!
>>
>> From the dump you sent, I don't see any leaks. Perhaps
>> some of those fragments increase over time. Can you make
>> a memory dump after the server runs some time, like after
>> it gets 100 messages?
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Solutions
>> www.opensips-solutions.com
>> <http://www.opensips-solutions.com>
>>
>> On 03/06/2017 03:02 PM, John Nash wrote:
>>> Here is the dump
>>> http://pastebin.com/DTEHF5Vc
>>>
>>> On Mon, Mar 6, 2017 at 6:20 PM, Răzvan Crainea
>>> <razvan at opensips.org <mailto:razvan at opensips.org>> wrote:
>>>
>>> None of the "actions" you are talking about have big
>>> impact on private memory, but the shared one. Better
>>> do the dump and send it over to point out what is
>>> "eating" memory.
>>>
>>> Best regards,
>>>
>>> Răzvan Crainea
>>> OpenSIPS Solutions
>>> www.opensips-solutions.com
>>> <http://www.opensips-solutions.com>
>>>
>>> On 03/06/2017 02:39 PM, John Nash wrote:
>>>> with every call attempt it decreases. I tried some
>>>> changes by rejecting invite before drouting call
>>>> (That means after auth , dispatcher) and found
>>>> memory is stable but when drouting sends Invite to
>>>> external gateway and external gateway rejects it.
>>>> Then this issue happens.
>>>>
>>>> Inuse transactions and active dialogs also 0.
>>>> Somthing wrong happening in handling of failure
>>>> replies. But apart from use_next_gw and setting
>>>> some avps for CDR not much going on there.
>>>>
>>>> On Mon, Mar 6, 2017 at 5:54 PM, Răzvan Crainea
>>>> <razvan at opensips.org <mailto:razvan at opensips.org>>
>>>> wrote:
>>>>
>>>> Ok, so it is the first listener for the private
>>>> IP that leaks. Next, is the memory stabilizing
>>>> in time? Or it is continously decreasing?
>>>> Yes, that's how you should make the dump.
>>>>
>>>> Best regards,
>>>>
>>>> Răzvan Crainea
>>>> OpenSIPS Solutions
>>>> www.opensips-solutions.com
>>>> <http://www.opensips-solutions.com>
>>>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>
>
>
>
> _______________________________________________
> 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/20170307/a4ce688d/attachment.html>
More information about the Users
mailing list