[OpenSIPS-Users] Quest to find memory leak

[John Nash]

version: opensips 2.1.5 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
git revision: 39b19dd
main.c compiled on 19:27:59 Mar  5 2017 with gcc 4.4.7


On Tue, Mar 7, 2017 at 4:25 PM, Răzvan Crainea <razvan at opensips.org> wrote:

> What allocator are you using? Can you post the output of 'opensips -V'?
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 03/07/2017 12:23 PM, John Nash wrote:
>
> Please note when i call do_routing in such a way that its unable to find
> any rules matching and reject call i do not see free memory drop. But if it
> finds a route, sends call to that gateway memory drops with each attempt.
>
> On Tue, Mar 7, 2017 at 3:17 PM, John Nash <john.nash778 at gmail.com> wrote:
>
>> only 6 or 7 calls
>>
>> On Tue, Mar 7, 2017 at 3:09 PM, Răzvan Crainea <razvan at opensips.org>
>> wrote:
>>
>>> 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 Solutionswww.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>
>>> 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 Solutionswww.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>
>>>> 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>
>>>>> 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 Solutionswww.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>
>>>>>> 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 Solutionswww.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>
>>>>>>> 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 Solutionswww.opensips-solutions.com
>>>>>>>>
>>>>>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing listUsers at lists.opensips.orghttp://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
>>
>> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://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/a25edbb8/attachment-0001.html>