[OpenSIPS-Users] Quest to find memory leak

[John Nash]

OK..May i send you my script privately?

On Thu, Mar 9, 2017 at 6:13 PM, Răzvan Crainea <razvan at opensips.org> wrote:

> Hi, John!
>
> No, I nothing is suspicious. Definitely not from the drouting module.
> Try to make two captures: one after 10 calls, another one after 20 calls.
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 03/09/2017 01:50 PM, John Nash wrote:
>
> Do you see anything suspicious in the latest mem dump?
>
> On Wed, Mar 8, 2017 at 7:20 PM, John Nash <john.nash778 at gmail.com> wrote:
>
>> One more useful info. I disabled drouting functions and just rewrote RURI
>> to hardcoded address keeping rest of the functions same and I do not see
>> drop in private memory of that process.
>>
>> On Wed, Mar 8, 2017 at 4:40 PM, John Nash <john.nash778 at gmail.com> wrote:
>>
>>> OK Here is the dump
>>> https://drive.google.com/open?id=0BxJKNwFalcRMX0xDUlRIa2VUdG8
>>>
>>>
>>> I increased syslog message rate to 500000, Made around 10 call attempts.
>>> Waited for some time and made sure no call is on server and then sent
>>> signal to dump memory to the process ID i suspect.
>>>
>>> On Wed, Mar 8, 2017 at 4:07 PM, Răzvan Crainea <razvan at opensips.org>
>>> wrote:
>>>
>>>> No, you should not kill any process. Simply send a SIGUSR1 to the
>>>> process you suspect.
>>>>
>>>> Răzvan Crainea
>>>> OpenSIPS Solutionswww.opensips-solutions.com
>>>>
>>>> On 03/08/2017 12:28 PM, John Nash wrote:
>>>>
>>>> Sorry...Should I kill only the process where i see memory leak?
>>>>
>>>> On Wed, Mar 8, 2017 at 3:41 PM, Răzvan Crainea <razvan at opensips.org>
>>>> wrote:
>>>>
>>>>> use only memdump set to 1.
>>>>>
>>>>> Răzvan Crainea
>>>>> OpenSIPS Solutionswww.opensips-solutions.com
>>>>>
>>>>> On 03/08/2017 12:11 PM, John Nash wrote:
>>>>>
>>>>> Ok i will give another try what should be the values of memdump and
>>>>> memlog
>>>>>
>>>>> On Wed, Mar 8, 2017 at 3:13 PM, Răzvan Crainea <razvan at opensips.org>
>>>>> wrote:
>>>>>
>>>>>> Hi, John!
>>>>>>
>>>>>> The traces you showed me are incomplete: they do not have all the
>>>>>> memory chunks allocated, thus I can't say wether something is wrong or not.
>>>>>> As I said earlier, it is normal for opensips to use extra memory
>>>>>> every call. But after a while, this should stabilize. After a while might
>>>>>> mean more than 1000k calls. As long as you never reach the upper limit of
>>>>>> the memory, you can't conclude that there is a memory leak. Even then,
>>>>>> you're limit might be too low for the kind of traffic you are doing, so it
>>>>>> still might not be a memory leak. But only then it is worth to investigate.
>>>>>> When we investigate, we need all the data (i.e. the entire trace of
>>>>>> the memory dump).
>>>>>> So please try to send as many calls as possilble, and if this issue
>>>>>> still persists, make a pkg memory dump when the server is in idle mode and
>>>>>> send it over.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Răzvan Crainea
>>>>>> OpenSIPS Solutionswww.opensips-solutions.com
>>>>>>
>>>>>> On 03/08/2017 11:26 AM, John Nash wrote:
>>>>>>
>>>>>> any suggestion for me?..should i try to crash opensips by sending
>>>>>> many calls?
>>>>>>
>>>>>> On Tue, Mar 7, 2017 at 4:54 PM, John Nash <john.nash778 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>> 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
>>>
>>> _______________________________________________
> 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/20170309/fecee3e8/attachment-0001.html>